El Cap and Adobe Temp Install Account

Since upgrading yesterday, I'm having issues with Casper Imaging 9.81 putting down 10.10.4 image that worked fine with 9.65, so far it seems only computers with multiple partitions.

I know if I use anything below casper imaging 9.81 - computer reboots fine but gets stuck in the adobe install account, so that's out.

If I image an Air with 9.81 with a config that doesn't have multiple partitions, it seems to image fine and reboots to adobe install account and installs software and reboots to login screen as it should..

If I image same Air with config with recovery partition and autorun data, it never works, reboots to folder with question mark. If I delete computer from JSS and image it with a config with a recovery partition, so far in my testing, it successfully reimages, boots to adobe account and reboots to login screen 4/5 times. That 1/5 times after image comes down it's rebooting to netboot instead of macintosh HD. Once in netboot that 1/5 times, if I manually set startup disc to Macintosh HD, it reboots to adobe install account.

I thought it was an autorun flukey issue so I tried imaging a few times not deleting computer but not saving autorun data on computers with partition, but they booted to questionmark too. When I hold down option key, the only options are EFI boot, recovery partition, and netboot servers, no mac hd.

I have worked with one of the JAMF support tech on this one. You have to make sure that Caper imaging is on 9.81, recreate your netboot to 10.10.3 at least. AutocasperNBI and Autodmg does not work with 10.10.5 and El Capitan yet. ALso when you create the netboot on autocasperNBI make sure you go to options => advanced and check Install modified rc.netboot file This fixed my problem with the Adobe Temp Account when imaging Yosemite and Mavericks but not on El Capitan. For some reason, with El Capitan the Adobe Temp Account is coming up again. I will try the suggestions above and see if I have luck.

@Randydid Try 123456 on the passcode. We got that too and We googled it and said just use 12345 passcode worked for us.

Hey everyone, I wanted to post to everyone so this information is readily available.

Looks like we are running into D-009788. The JAMF helper is hanging and not completing the post-install reboot. Any packages that we have checked for, Installing on boot drive after Imaging, we can run as policies to install those at check-in to avoid getting stuck at that screen.

EDIT: The defect that was filed was closed as unreproducable. At this time we are seeing some reports of the JAMF Helper "Please wait while we finish installing software" does not appear, yet boots to an temporary AdobeInstall account. From what I have seen in a few environments, if you do not do anything to the computer, it will reboot and finish all post-install tasks.

Again:
If you are experiencing this issue, please reach out to your TAM and let them know of this defect so we can get some visibility on it.

Thanks,
Tiny
JAMF Support~~

@Kumarasinghe Do you have more information on the purpose of _mbsetupuser? We're seeing a "_mbsetupuser" folder added to the root of the hard drive after upgrading to El Capitan via Self Service and can't quite place what it is and why it's there.

I myself have been noticing _mbsetupuser and it's commandeering some of the login scripts we run before the initial user's identity changes.

I have a feeling the introduction of _mbsetupuser has caused Our DEP process requires a reboot in El Capitan (when you check management history, there's a pending command to install the JAMF binary which says the computer was busy -- a reboot fixes it, but this used to just go right through)

At least, that's my theory right now.

@cstout The reply we got saying this “_mbsetupuser” is for initial setup process of a new system.

I was having an issue with _mbsetupuser auto-logging in after the second reboot and forcing users to run through the setup screens. I created an ongoing policy that runs at enrollment complete that deletes the _mbsetupuser and haven't seen the setup screens since.

I Just wanted to thank everyone for working on this one. I had this same issue on Monday, but was able to get things working.

Info:

1. JSS 9.65
2. AutoDMG 1.54 - 10.11.1 image
3. AutoCasper - 10.10.3 boot image
4. Adobe CS6 Des/Web
5. Mid 2013 21 inch iMacs

Image would display problems as you guys noted above(Adobe temp account, stalled at iCloud login). I moved CS6 Deployment to munki and changed package to requires restart, which kick off 1st boot setup script, no issue for past 48hrs

Cheers

@LSinNY you should really be on JSS 9.8.x for 10.11 FWIW.

I have seen it twice so far.

Casper Imaging completes its initial jobs and then after the second reboot, the Apple OEM OS X El Cap desktop/Finder/Dock appears and the Adobe Install user account is logged in. The black "Please wait while we finish installing software" screen does NOT appear.

Eventually the Mac reboots again.

This is certainly odd. It can cause users to think they are magically logged into the Mac, and thus they start interacting with the Mac while its still completing the deployment/install process.

JSS 9.8.1
JAMF client 9.8.1
OS X 10.11.3 image
10.11.3 NBI (AutoCasperNBI)
2011 iMac 27"

@Tiny - TAM notified!

Questions:

1) Is the Adobe Install account the same as the _mbsetupuser account mentioned above?

2) Is it safe to delete the _mbsetupuser account? I see that it exists on all JAMF-managed Macs, not just Macs imaged with Capser Imaging.

_mbsetupuser is purely an Apple implementation and I believe meant for usage during the setup assistant. someone else can hopefully clarify on that.
the adobe install user is a JAMF implementation for first boot install of packages.

Thanks.

The "_name" naming convention certainly felt like an Apple service account.

Chiming in here to confirm the existence of _mbsetupuser, some account details and context of occurrence.

While testing OS X El Capitan upgrades (via Self Service policy), I noticed iCloud setup screen re-asserted itself, so I was checking out Trouton's kb Suppressing iCloud & Diagnostics on El Cap via Profiles

While waiting at iCloud setup screen our screen saver password policy kicked-in and only shows "Setup User" for screensaver unlock. This account & password is unknown, so I had to force logout/reboot. This raised a few questions (and lead me here).

Assuming Trouton's profile approach resolves the iCloud re-prompt, this timing issue for our El Cap upgrades and screensaver lock shouldn't be a common occurrence (for my org).

I'm mainly noting info about this account's existence and it's creation and intended function.

So far the account has persisted a second reboot and probably will until (a) I suppress iCloud setup and/or (b) remove the account outright?

This user account is also listed in /Library/Managed Preferences/ (we're using profiles, so I'm sure you know why these folders exist).

Here's a summary of details from a test Mac...

dscl . read /Users/_mbsetupuser

# Except of details...
NFSHomeDirectory: /var/setup
Password: ********
PrimaryGroupID: 248
RealName:
 Setup User
RecordName: _mbsetupuser
RecordType: dsRecTypeStandard:Users
UniqueID: 248
UserShell: /bin/bash

I tested the profile fix one time and it didn't work for this issue... the profiles are pushed to the Mac after I think

C