help suppressing iCloud prompt on first boot: autodmg & 10.11.1

mathieu
New Contributor

Hello all,

I am having an issue similar to this: https://jamfnation.jamfsoftware.com/discussion.html?id=17622

I am using autodmg 1.54 to build a never booted dmg of 10.11.1 for re-imaging with El Capitan.
I have a number of pkgs in my Casper imaging config that are installing on reboot. However, when it reboots it is going to the iCloud login prompt instead of the jamfhelper ‘busy imaging’ curtain while it installs everything. With the Adobe suite, that means it can sit there for a long time like that, which is potentially confusing to our other techs.

I think I had issues similar to this in Yosemite but used a payload-free-pig to kick off jamfhelper on reboot which superseded any other nonsense beneath the curtain. In El Capitan when I do that, my jamfhelper curtain hangs the reboot post first-run.

I have a 1st run script that runs on reboot via Casper as well. In it I have embedded items from @rtrouton 's script to suppress the iCloud prompt, which works great subsequent to this first reboot. I thought maybe it was running too late in the startup process, so I moved that part out into a launchdaemon & script, installed on the target volume prior to reboot. Now that is running earlier during boot now, but I think because the account it’s booting into is the new _mbsetupuser, which appears to be created on the fly on first boot in /var/setup, it has no effect. I tried pointing the launchdamon/script to /var/setup specifically, but I think there is an issue with timing.

Is this unavoidable? Any beloved alternatives working well with 10.11?
Thanks!

2 ACCEPTED SOLUTIONS

Aziz
Valued Contributor

This is a known bug with OS X 10.11.1 and JSS 9.81. I contacted my TAM to file a bug.

View solution in original post

Aziz
Valued Contributor

@mathieu

Below is a very simple script that should launche the JAMF Helper upon enrollment. If we put the script below in a policy that runs on enrollment, the JAMF Helper would take over.

/usr/local/jamf/bin/jamf launchJAMFHelper -path '/Library/Application Support/JAMF/bin/jamfHelper.app'

View solution in original post

6 REPLIES 6

Aziz
Valued Contributor

This is a known bug with OS X 10.11.1 and JSS 9.81. I contacted my TAM to file a bug.

mathieu
New Contributor

Thank you @Abdiaziz. Just opened a case with my TAM for this as well.

Anyone have any ideas about how else to get a lock screen up (or anything more useful than the iCloud login prompt) during that first boot in the meantime? Besides old skool capturing a booted OS, am mostly out of ideas.

Aziz
Valued Contributor

@mathieu

Below is a very simple script that should launche the JAMF Helper upon enrollment. If we put the script below in a policy that runs on enrollment, the JAMF Helper would take over.

/usr/local/jamf/bin/jamf launchJAMFHelper -path '/Library/Application Support/JAMF/bin/jamfHelper.app'

mathieu
New Contributor

Thank you @Abdiaziz . That worked for me in Yosemite, but in El Capitan when I did your command via a script-only pkg, the jamfhelper curtain did not quit and hung reboot indefinitely, preventing the Mac from rebooting even when all installations were completed.

(Then when I force-quit jamfhepler via ssh and rebooted, for some reason the whole jamf first run script ran again, RE-installing all of the items set to run at reboot at imaging :(

I'll try it out as a one-liner on enrollment and see if results are different.

bpavlov
Honored Contributor

It's not just for "some reason". If you haven't ever done this, I suggest you image a computer and don't force a reboot on it. If you're in a netboot environment, have a peek at /Library/Application Support/JAMF/FirstRun. Otherwise target disk mode the computer and then navigate to that folder. Read the scripts and what it's doing on first boot. Particularly if the first boot process is interrupted and reboots before the first boot scripts finish, then it will resume the next time the computer starts up.

mathieu
New Contributor

OK, I figured out thx to @Abdiaziz , noticed my jamfhelper call was pointing to the old binary location (upgraded my jss recently). So the work around is successfully in effect again.

This still seems like a bug, so will continue follow-up with my TAM, since jamfhelper shouldn't need help.

Thank you for the point of interest re: FirstRun script @bpavlov . Always learning:)