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, 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)
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?
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.
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 :)
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.
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.
@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:
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.
@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.
@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.
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.
@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.
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.
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!
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.
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.
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.
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.
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
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.
JAMF client 9.8.1
OS X 10.11.3 image
10.11.3 NBI (AutoCasperNBI)
2011 iMac 27"
@Tiny - TAM notified!
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.
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