Automated High Sierra Upgrade with nobody logged in?

[CCNapier]

We are a University with open access labs with a lot of Macs.
There are no admins that use the computers, they are used by students who are restricted. It's therefore difficult to try to push macOS upgrade.

This is actually our first in place upgrade we are trying.

I want to deploy High Sierra, but have been hitting a wall at almost every turn.
What I want to do is wake the machines at 1am, and start the installation when nobody is logged in. Is that possible?

I tried simply uploading the installer app, caching it and then installing cached. It works under certain circumstances (seems OK directly after a reboot, on a VM), but caused no end of problems on real devices (reboot loops/panics even though the hardware is reasonably new and supported by the OS).

I've seen scripts around using the startosinstall command, but when I launch this when nobody is logged in (after deploying the app in a package nad testing with recurring checkin), it appear that nothing happens. And install.log doesn't really give you a hint.

I'm trying to find a definitive answer for upgrade; there's a lot of threads out there, but mostly seem to deal with self service...

[jan_rosenfeld]

so I just finished a JAMF 300 course, and the instructor mentioned that specifically for the high Sierra installer, it has to be run with some sort of user initiation. It's just a byproduct of the way apple is distributing this particular update. once you're on 10.13, future updates can be done via policy/script/whatever. but this particular jump has to be done by somebody running the installer.

just what I heard from a JAMF instructor. maybe it has to do with the new file system or something

[Nix4Life]

@CCNapier

if you are able to look at other tools and don't mind a little bit of work, you can do this with JAMF Pro and Munki. I set this up for a friend last month. They were doing a combination of upgrade methods. Of course this is all based on your time table

[CCNapier]

So I've been playing about before I saw these messages.
I have an "unattended / non logged-in" upgrade working from 10.11 to 10.13, but need to do more testing. This is rather basic, and needs a script to catch stuff, but you get the gist:

1) I download High Sierra from the App Store.
2) Use composer to create a package that contains /Applications/Install macOS High Sierra.app
3) Create a Jamf Policy to deploy the .app and Execute Command:

sudo /Applications/Install macOS High Sierra.app/Contents/Resources/startosinstall --applicationpath /Applications/Install macOS High Sierra.app --agreetolicense --converttoapfs NO --nointeraction

This seems to work so far...

[jan_rosenfeld]

@CCNapier interesting. if you get this consistently working in production, please post here and let us know!

[jmahlman]

We have a 10.12 -> 10.13 upgrade in place working with the method listed above.

Our script looks like this:

#!/bin/sh
/Applications/Install macOS High Sierra.app/Contents/Resources/startosinstall --applicationpath "/Applications/Install macOS High Sierra.app" --volume $1 --rebootdelay 30 --nointeraction

Works like a charm.

[donmontalvo]

@CCNapier how does that command work out if you're using --converttoapfs NO? HDD (including Fusion drives) are not converted to APFS.

How to choose between APFS and Mac OS Extended when formatting a disk for Mac
https://support.apple.com/en-us/HT208033

Which format should you choose? When you install macOS High Sierra on the Mac volume of a solid-state drive (SSD) or other all-flash storage device, that volume is automatically converted to APFS. Fusion Drives, traditional hard disk drives (HDDs), and non-Mac volumes aren't converted.

Does your command prevent SSD from being converted to APFS?

I'd imagine best practice would be to follow Apple's lead, and allow SSD to be converted to APFS, and to allow HDD/Fusion to not be converted.

[donmontalvo]

@CCNapier wrote:

This seems to work so far..

@jmahlman wrote:

Works like a charm.

I guess the old saying goes...You pays your money, you takes your choice

[donmontalvo]

@jan.rosenfeld I wonder if your instructor meant High Sierra Combo Updates? We know Apple dropped the ball there.

With all due respect to our wonderful Apple Rep...thanks for nothing, Apple. #shakesFistAtApple
https://www.jamf.com/jamf-nation/discussions/27003/with-all-due-respect-to-our-wonderful-apple-rep-t...

...and:

Errors Deploying 10.13.3 Combo Update
https://www.jamf.com/jamf-nation/discussions/26846/errors-deploying-10-13-3-combo-update

[jan_rosenfeld]

@donmontalvo i think you are right. My intitial tests and attempts ran into the exact problems described in those threads.

Since the combo update however I’ve had great success with a reboot -background flag

[engh]

@CCNapier As others mentioned, the High Sierra (and Sierra) installer with the startosinstall command works like a charm and we have successfully used it on our public labs for automated installs. We also use it in Self Service for manual upgrades. There are some instances where it hasn't restarted to the installer but that seems to mostly affect older (10.9.5?) OS's (not public labs).

If you are looking to check to see if someone is logged in, you can use a script to check to see if there is a "Dock" process running and if not, call your cached Install app.

#!/bin/sh
userSession$( pgrep "Dock" )
If [[ $userSession != "" ]]; then
     echo "computer is currently in use"
else
     /Applications/Install macOS High Sierra.app/Contents/Resources/startosinstall --applicationpath /Applications/Install macOS High Sierra.app --agreetolicense [--converttoapfs NO] --nointeraction
fi

We have been allowing conversion to APFS so we don't use that option.

Caveat: My logic is sometimes backwards - I often have to reverse my "If" statement logic!

Cheers!

-Dan

[donmontalvo]

Two ways to test console user...

New as per Apple, supports Fast User Switching

$( python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "
");' )

Old way still works, but doesn't support Fast User Switching

$( ls -l /dev/console | awk '/ / { print $3 }' )

If root owns console, you're at login window, or a field tech has gone mad.

[CCNapier]

@engh I have seen JAMF notes about Sierra upgrade not working on 10.9 and below. Instead you need you need to do an incremental upgrade (say to 10.11 first).

@donmontalvo the no apfs convert command was being used just because I pulled the command from somewhere else and I haven't edited it. Likely I will just remove that parameter (and also examine other parameters) before rolling.

Just to confirm to all that my process seems to be working so far. I still have to test on "difficult" machines (that may have more specialist/problematic software), but I've been getting perfect upgrades in tests whereas I didn't before using other methods.

[CCNapier]

I'm getting issues that I had previously on "live" machines

When the command is attempted when nobody is logged in, the following errors appear (whether or not using the convertAPFS yes or no)

osinstallersetupd[41068]: isConvertableToAPFS: was called on a APFS disk. osinstallersetupd[41068]: Target is not convertible to APFS: This volume is not formatted as Mac OS Extended (Journaled). osinstallersetupd[41068]: isConvertableToAPFS: was called on a APFS disk. osinstallersetupd[41068]: Target is not convertible to APFS: This volume is not formatted as Mac OS Extended (Journaled).

Even though the disk , the ONLY disk, is Journaled.

However, if I SSH as an admin and run the startosinstall command from terminal, it looks to be working! ARGH. But why not from a script when nobody logged in???

[mconners]

Hey @CCNapier and @engh I have been having a few issues getting this to work and I wonder if your script/command is still working. In my testing up to a month ago, things were fine. The past couple of days in live labs we are getting mixed results.

I have read one site that says for the startosinstall binary to work, it requires a logged in user. I'm trying to confirm with Apple support if this is true.

The other thing I am contemplating is whether or not when we package up macOS High Sierra.app from the App Store in Composer, if this package, which is a dmg, needs to be in an APFS or will HFS+ format. Consider this is only for our Macs already on high Sierra 10.13.4 or higher.

Thoughts?

[engh]

@mconners We package up the macOS High Sierra.app into a PKG so APFS/HFS+ doesn't come into play.

So far as I'm aware, it is still functioning. Our current policy does a "shutdown -r now" command at the end and so policy logs generally don't get captured. Ran into issues where Self Service would stop the machine from restarting. I imagine we would have heard from our desktop support staff it it was not working though?

One thing we did find out though is the -eraseinstall ONLY works on drives that are already in APFS format.

@CCNapier 10.9 does NOT work with the command. You do have to incrementally upgrade the device. The installer does drop into the /Applications/ folder but never launches.

[mgshepherd]

I wanted to inquire how users are going about automating either a 10.12->10.13 High Sierra upgrade or doing a High Sierra "--eraseinstall" method at the login screen. I have tried using a policy method (contains the installer package and execute command), using JAMF Remote and finally ARD unix commands. Every time the command for either performing an upgrade or doing an eraseinstall, the session is left open and/or the policy stays in a pending state. I never actually get a completed status even though it had worked. Is there any way to include extra code so that it can be reported back to the JSS that the policy was successful.

Below is what I'm using via execute command to either upgrade or eraseinstall depending on the situation:

Erase Command

/Applications/Install macOS High Sierra.app/Contents/Resources/startosinstall --eraseinstall --newvolumename "Macintosh HD" --agreetolicense &

Upgrade Commanad

/Applications/Install macOS High Sierra.app/Contents/Resources/startosinstall --applicationpath /Applications/Install macOS High Sierra.app --agreetolicense  --nointeraction

Thanks!

[roiegat]

Anyone having recent issues with using the 10.13.5 installer for High Sierra? When I give it the command:

/Applications/Install macOS High Sierra.app/Contents/Resources/startosinstall --applicationpath /Applications/Install macOS High Sierra.app --agreetolicense  --nointeraction

I get back:

/Applications/Install macOS High Sierra.app/Contents/Resources/startosinstall: command not found

Looking at the installer package contents the file startosinstall is there...but just doesn't seem to run. Anyone else having this issue with the 10.13.5 installer? I have a 10.13.2 installer that works fine...but with the Touch Bar issues, I'd rather just upgrade the 10.12 machines to 10.13.5 instead of 10.13.2 and then run the update which might put them in a critical update loop.

Suggestions?

[marklamont]

I'm using this;

<path to installer>startosinstall --eraseinstall --newvolumename "Macintosh HD" --agreetolicense &

and that works ok for a reset on apfs devices.

[gweinisch]

I've created a policy for this using the method outlined by @CCNapier above, for the purpose of upgrading our Mac labs. However, after running the upgrade process for about 40 minutes on a test machine, it returns to a login screen. At that point, once a user logs in, the upgrade process continues for another 10 minutes or so, and then completes successfully. I'd really like to get this fully-automated and to not require user intervention. Am I missing something here?

[kevin5495]

@gweinisch I'm having the same issue with the installer starting again. Logging into all lab machines isn't really an option. It does work when updated manually, also not an option.

[taugust04]

@gweinisch and @kevin5495 thanks for explaining some of these issues. By any chance, do you lose the ability to ping these systems when they get "stuck" during your automated upgrade process?

I'm experiencing what I believe is the same issue when trying to execute an upgrade of 10.13.5. If I trigger the policy while logged in via Self Service, the upgrade finishes without issue. If I trigger the policy while no one is logged in via ssh it gets "stuck" and I lose network connectivity to the systems as well.

Apple is certainly making it frustrating for IT admins these days. I try to roll with the punches but it seems like they are really reducing the amount of automation being allowed for any sort of operating system install or upgrade... argh... are we looking at an macOS installer bug that needs to be reported to Apple?

[gweinisch]

@taugust04 I just tried this again, and found that the client had network connectivity once it had returned to a login screen (the point at which the upgrade process stops, pending a user login in order to complete the process). In addition, I tried completely revamping my upgrade policy using the script found here:

https://github.com/kc9wwh/macOSUpgrade/blob/master/macOSUpgrade.sh

This was suggested by Jamf support. Interestingly, the end result is still the same- Test machine returns to a login screen, and once a user logs in, they get a progress bar and the message "Completing Installation: About 13 minutes remaining".

[taugust04]

@gweinisch thanks for your reply. I may be encountering something different then. I don't have physical access to the systems that are having this problem so I'm going to have to dispatch a colleague to investigate, since I'm still unable to connect over the network to the two systems that I triggered the upgrade from using SSH.

[CCNapier]

We have experienced some bad upgrades, and we haven't been able to work out why.
Test scenarios work fine, but some specialised labs seem to cause problems. We haven't had time to investigate and so have abandoned upgrades for these labs so far.

It does seem that some software may well be getting in the way

[alv2015591]

The 13 minutes after upgrade is a part of the upgrade process. It happens after the first login post upgrade. This is the future of our upgrade process from 10.13.5 and beyond. My 10.14 beta tests have done the same thing.

[monaronyc]

Does anyone know how to FORCE a restart on the logged in user so High Sierra can install no matter what apps or files they have open?

EDIT: Never mind! I added (TOTALLY FORGOT ABOUT THIS!) a restart option in the scripts policy to restart immediately on No User and User Logged in. Which worked!

[monaronyc]

Does anyone know why the High Sierra installer (10.13.6), brings the workstation back to a login screen and when the user logs in, the install is still running with 12 min left to install? Like is this normal? See screenshot:

[mark_mahabir]

@monaronyc It happens in Mojave too.

[monaronyc]

@mark.mahabir OH! Okay? Glad its not just us. But good to know. Thanks for the heads up!

[Jalves]

Hello. A few weeks ago I started testing my Mojave upgrade workflow using the MacOSUpgrade script from JAMF. I'm also experiencing the installation resuming for another 13 minutes after the user log in consistently. I just wanted to check in and see if this is still expected behavior of the installer if you do not use an auto login account as part of the upgrade process.

Thanks!

[allanp81]

@Jalves As far as I can tell it's a timing thing. If the mac is left after the upgrade and then logged into several hours later you don't see that extra screen, it'll just log in.

[apunsal]

@allanp81 Has this been tested extensively? We are looking to roll out upgrades overnight and I'm wondering what the exact number of hours would be.

[allanp81]

@apunsal I've never tested it specifically but it felt like a couple at least.

[mhasman]

Hello. Would any of commands above work for macOS Mojave installer?