Posted on 01-21-2015 12:16 PM
Hey Everyone, I appreciate your help on this in advance!
K-12 environment, AD Bound, mobile account set iMacs running 10.9.5, JSS v. 9.62. Yosemite Install policy, runs in background or self service once triggered, current payload is vanilla Install_OSX_Yosemite.InstallESD.dmg.
My goal is to run the 10.10.1 upgrade with no setup assistant/iCloud prompts or user prompts on AD bound Macs. So perfect world outcome would be: Upgrade policy runs, Mac reboots into installer, finishes and reboots to login screen waiting for network login.
The main issue is that we have enabled Mobile Accounts for AD (multiple other reasons for that), but no one will have logged into the Macs to set a "local" (mobile) account before the upgrade runs. We have a hidden local Admin account on the machines, but post install, the OS treats it like there is no local user account at setup and runs setup assistant asking for local account creation. That, and I'd rather not have all the setup questions asked.
I imagine this will entail some pre/post flight scripting revolving around (adding) .AppleSetupDone? Removing the iCloud prompts would be great so the students can't enable FileVault, but not as crucial not having setup assistant run.
Posted on 01-21-2015 01:09 PM
I know theres strong views flying around the Internet saying its not "the done thing" writing into the user template, and I'm currently looking at migrating all my first boot script stuff (ideally) to config profiles, but for now I still use the same method as @rtrouton, adding the necessary keys into the user template and existing home directories.
Have a look at the derflounder guides on the specifics. You need to suppress iCloud and the diagnostics screens to meet the no prompt goal.
Posted on 01-21-2015 01:24 PM
I would second what /url">@davidacland][/url said. This is the only method that constantly worked for me. [Here's the script, btw.
Oh...and you are probably going to want to 'unhide' your local admin account or create a temporary admin account that is not a sub-500 account when you run your upgrade policy. If the upgrade does not detect a local admin account, it will wipe out your non-system sub-500 accounts and then bring up the setup screen after the upgrade.
Posted on 01-21-2015 01:32 PM
@rtrouton replied to me in another thread with his most recent suppression of iCloud/diagnostics script. Seems I just need to get the script to run immediately after the OS upgrade completes at startup. It is here:
The bigger problem is exactly what you stated, denmoff. Because there is no un-hidden local accounts, the setup assistant runs. That is the main thing I want to stop. I'd rather just stop the setup assistant from launching rather than unhiding our account or creating a new local account. Any ideas?
Posted on 01-21-2015 01:39 PM
The problem is with how the upgrade itself works. I don't think you can avoid unhiding an admin account during the upgrade. You just need one unhidden (admin?) account. After the upgrade runs, you can have a script run to delete it or re-hide it.
Edit: I should have made it clear that you can script the creation of the temporary local admin account to run before the upgrade runs. And then setup another policy that checks for 10.10 clients and removes the local admin account.
Posted on 01-21-2015 01:46 PM
OK - at second thought that isn't so bad. So to clarify: Prior to running the 10.10 upgrade policy, create a temp local account, run the 10.10 upgrade policy, run iCloud suppression script, delete temp local account?
Any thoughts on how to get the suppression script to run directly after the 10.10 upgrade before anyone has a chance to login? The JSS won't know the machine is on 10.10 until the next recon so a startup script scoped to 10.10 machines won't work right away.
EDIT: I think I answered my own question. A simple sudo jamf recon startup script scoped to all managed clients would run on first reboot after the 10.10 upgrade. Then the suppression script can be scoped to a smart group containing 10.10 clients.
Posted on 01-21-2015 01:54 PM
You could use the createOSXinstallpkg from here:https://github.com/munki/createOSXinstallPkg and put the script into a payload free package using first boot package.kg here: https://derflounder.wordpress.com/2013/05/13/first-boot-package-install-pkg/.
Posted on 01-21-2015 02:40 PM
Are you sure its not the /var/db/.AppleSetupDone file that you need to create? If that file does not exist, the initial setup assistant where you are prompted to create a user account is presented upon reboot.
Easy fix is to do something like # touch /var/db/.AppleSetupDone
Also I thought the sub 500 uid account getting wiped on upgrade was only an issue for 10.7 to 10.8 ( and perhaps earlier)
10.8 to 10.9 was not a problem? I haven't tested a 10.9 to 10.10 upgrade so I could be wrong and to be honest it wouldn't surprise me if this regression has occurred in 10.10, but I certainly haven't heard screaming about it and i would expect to hear something if it was the case.
But for sure the way to go would be as @davidacland mentioned use createOSXinstallpkg and use the first boot package installer.
Also for Yosemite you might want to check out this as well as there are some changes to the way yosemite handles the packages
Posted on 05-18-2015 12:23 AM
What also worked for me to suppress the iCloud Assistant:
You can deploy a Device/System Profile with the respective keys
Posted on 08-19-2016 07:54 AM
location of the file to delete or rename to permanently (until next update) disable setup assistant is: /system/library/CoreServices/Setup Assisant.app/Contents/MacOS/Setup Assistant
rename or delete.
you can access this if you netboot to your nbi and use finder to open MacintoshHD
Posted on 08-20-2016 10:30 AM
@dlang As mentioned, you need to do this from another volume under 10.11 due to SIP.
However, don't do it.
There are a few more config profile options for suppressing the SetupAssistant screens in 9.93 for 10.11.
Use them, leave the app be.
Posted on 10-04-2016 06:47 AM
even with those options, setup assistant still loads and takes time, almost doubling the login time.
I run a lab with a few hundred machines. My solution solved my problem. nothing mentioned anywhere else did.