El Cap and Adobe Temp Install Account

[Randydid]

Hi JN,

I thought I would get a jump on my testing/building an El-Cap image and environment. I downloaded the bits for 10.11 and went through the AutoDMG process and came up with a nice (reasonably) small 8GB DMG. I dropped it into Casper Admin, etc.

Problem: I can drop a plain image of El Cap just fine. It comes up to the normal login screen and I can login with my predetermined management account.

If I create a Configuration with even just one app (in this case, Office 2016), the image comes up with the iCloud login (which I skip past), and then presents me with the El Cap desktop and wallpaper. I was immediately puzzled as I had not set any other parameters such as auto-login, etc. I checked the login account and it is the Temporary Adobe Install Account.

I am running 9.81 in my test environment. I have tried removing Office 2016 and adding things like Fugu, XQuartz, or others and the result is the same. I have been using a machine that is not scoped for any policies ( https://jamfnation.jamfsoftware.com/discussion.html?id=4342 ). Tried the script mentioned here: https://jamfnation.jamfsoftware.com/discussion.html?id=10297

No searching has revealed any useful info.

Thanks in advance.

Your canary in the coal mine,

/randy

[andrew]

I've had this happen a few times in previous versions. Long story short, try this:
1. Have your scripts run "at reboot" 2. Make sure that packages have "Install on Boot Drive after imaging" checked.

[mm2270]

Randy, have you checked any of the packages you've been added to see if the Install on boot drive option is checked on them? If so, it would be putting those packages into a first run phase, which means they won't get installed until after the Mac boots (hence the Temporary Adobe Install Account - really wish JAMF would change the name of that account by now)

[Randydid]

Actually both of you gave me a clue. However, I had to UNCHECK Install on Boot Drive After Imaging on any packages I happen to want to add to my Managed Preference Profile. So, I tried that with Office 2016 only and it behaves as expected. This is different than my Mavericks and Yosemite configs. Most of my packages were set to Install on boot drive after imaging and the Adobe Account Installer issue never happened. Undocumented feature or not?

[dan_kubley]

Are you also using Casper Imaging version 9.81 with your JSS 9.81? I have seen this exact behavior when mixing Install on Boot Drive packages with an older version of imaging than what the JSS is on.

[Randydid]

UPDATE:

I have noticed that my Yosemite and Mavericks Configs are now exhibiting this behavior as well. I have unchecked the box on the packages in those configurations and am in the process of dropping those images on test machines. Looks like this might be a bug introduced in 9.81-at least here in my environment.

I will update this update after I confirm I can fix it by unchecking Install on Boot Drive After Imaging.

/randy

[mojo21221]

Perhaps verify you are using Casper imaging 9.8.1 when pushing your image out to your test machine. I had a similar issue when testing my 9.8 environment as the temp adobe account couldn't finish performing its magic due to my initial Casper imaging app being 9.65. Basically it seems that with the change in client framework the temp adobe login could not handle the updating of the client while finishing installing the packages that were scheduled to install on boot drive after imaging. Hope this helps :)

[Kennedy]

I can confirm I had the same issue, and updating our Netboot image to 9.81 has solved the issue.

Good luck!

[DBrowning]

I too was seeing an issue once i upgraded JSS to 9.8 and my imager was still at 9.7x. Once i updated the imager to 9.8 everything went back to normal.

[Aziz]

To fix this issue, everything has to match.

JSS on 9.81 and your Netbot set should also be on 9.81.

[Randydid]

@dan.kubley You may just have nailed it! My netboot clients are a couple behind. I will have to update those and then see what happens!

Stay tuned....

/randy

[Aziz]

I take what I said back. I'm also having this issue. Netboot is on 10.10.5, JSS/Casper imaging on 9.81 and the JAMF Helper will not show.

[Randydid]

I just updated my environment to 9.81 and rebuilt my NBI to 10.10.5 too. Still having the issue.

[bryce_carlson]

Having the same issue as @Diddel . On v9.81 JSS and made a fresh 10.10.5 NBI with Imaging v9.81; still no dice. 9.81 bug?

[Randydid]

UPDATE:

I have had mixed luck since updating the Imaging client and my NBI. I have three machines: A 21.5" iMac, a 12" Macbook, and a 15" Macbook Pro Retina.

I was able to get the iMac to complete once without interruption, and then it went back to the Adobe Installer on subsequent image attempts. I then rebooted that iMac and it picked up with the 1st Run routine and completed OK. Not sure what is going on there.

The MBP finished with no issues.

And the 12" Macbook came up to a screen asking for a 6 digit Passcode screen. I do NOT have FileVault enabled anywhere in our environment and I have NO idea what it might be. So, I thought no problem! I will just boot to the NBI and use Disk Utility to erase the drive and start over. A padlock and a field to enter text just appears. At this point, I cannot do anything with this Macbook-it is a brick.

[DBrowning]

if you have sent a Lock Command to this machine via Casper you will need to type in the 6 digit code that was entered. If you go to the machine in casper and look at the machine then click on the History Tab. Click on the Mangement History and their will be a show next to the Lock Command.

[Randydid]

@ddcdennisb There is nothing in history and I did not send a lock command, nor is there any note of one being applied.

[bpavlov]

@Diddel You can get that screen as well if someone had logged into their computer using their iCloud account and via the iCloud account a lock/wipe command was sent to it. In order to get the device unlocked you will need to go to the nearest Apple Store, and provide the following:
1. identification
2. proof of purchase
3. a letter stating that you work for the company who purchased the equipment (needs to have company letterhead).

That was at least the process I had to go through last Fall. So yes, the computer is a brick, but it can be resolved.

[Randydid]

@bpavlov This particular Macbook was in the possession (briefly) of an employee that is no longer employed at my org. It is possible that he had it associated with his iCloud account and sent a lock/wipe command. I can prove the ownership but it will take some time to wade through the bureaucracy here at UNM to get it.

/randy

[bpavlov]

@Diddel It is a PITA to be honest. It's an argument to disable the use of iCloud if ever there was one. It took me about 2 week to get the information I needed when I went through this. Between talking to Apple Support online and in the Apple Store, a lot of people didn't know what to do. And in one case when I explained the situation to an employee, they thought I was talking about an iOS device since that's probably most common scenario (employee leaves company; their iOS device had their iCloud account and device cannot be re-activated after wiping it). It seems its rarer with Macs. But at least there is a process to unlock the device. Good luck.

[DBrowning]

@bpavlov if you or someone is still on good terms with the termed employee, they can login to their icloud account and remove the device from their account then releasing the lock.

other wise you're stuck with going through apples process.

[bryce_carlson]

Made a fresh-er NBI. With a fresh-er copy of 9.81 from JAMF. All is good now.

As for your iCloud lock issue @Diddel... In the past I had luck with our GSX live chat to help get that taken care of it it was on a DEP certified PO#. Not sure if that is still a prescribed way but if you have a self service GSX account it might be worth a try.

[Randydid]

@bryce.carlson I updated my NBI with a 10.10.5 and 9.81 client still have the issue. I have narrowed it down to a "FirstRun" issue. I am still testing but for now it looks like I can add apps that are .pkg and all runs smoothly. But if I put say, Firefox.dmg it barfs and comes up to the Temp Adobe account. I am going to try other .pkg apps and see if the theory holds.

@ddcdennisb The employee left on not so good terms and this might be a malicious act but I am not going to pursue that-it is an HR issue and they can fight that battle.

Stay tuned...

/randy

[tim_rees]

Hi Guys,

I seem to be having similar issues:

JSS is 9.81 Casper Imaging is 9.81 on a 10.10.5 NBI created with AutoCasperNBI

Installing 10.10.5 I have no issues, the pkg files run at reboot correctly, as to the scripts.
Installing 10.11.0 it worked once, then the second time I re-imaged the pkg's don't install, and the scripts don't run.

Any ideas?

Thanks,
Tim

[ryan_s]

I too am running into this issue (temp Adobe account) after we recently upgraded our JSS to 9.81. I saw on some other posts here that this may be related to Netboot Casper Imaging version and JSS version being out-of-sync -- for us our NBI utilize Casper Imaging 9.72 and the JSS is 9.81.

I have been trying to upgrade our NBI's as well, using AutoCasperNBIv1.2.1 and El Capitan, but the AutoCasperNBI build errors out mentioning a "...dock.plist" file it cannot remove (@bentoms ...any ideas?). So I am taking a step back and upgrading our NBI to 9.81 and using 10.10.5 instead for now... that is unless anyone has had luck with 10.11 and AutoCasperNBI and cares to share!

[Kumarasinghe]

This might have to do with _mbsetupuser initial user login which was introduced in OS X 10.11

[CasperSally]

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.

[kimakd]

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.

[lucas_nelson]

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~~

[cstout]

@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.

[jbarnes]

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.

[Kumarasinghe]

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

[MacMaul]

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.

[Nix4Life]

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

[bentoms]

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

[dstranathan]

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.

[bpavlov]

_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.

[dstranathan]

Thanks.

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

[seabash]

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

[gachowski]

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