Let me shake my fist to the heavens for a moment: Jamf is an expensive product that touts it's zero day preparedness. When support consists of a series of techs clearly not reading the full details of the information you provided and then referring you to Jamf message boards and githubs as a possible solution (things you already done, "Hey there zero day experts, I know how to read and google, ok guys? Thanks!)
Here's my issue: we have mac labs, I want to upgrade them to Mojave (in place upgrade, nothing fancy, just good old fashioned upgrade, I don't want end users to have to work about it or deal with it, I want them to come in the next morning and log in and see that they are now on Mojave--nothing crazy, right?)
I used DEP and package and download to get Mojave on the machines. I've used ARD and Jamf Policy to run this command on Macs: /Applications/Install macOS Mojave.app/Contents/Resources/startosinstall --agreetolicense --nointeraction
I also went through the upgrade process manually logged in as an administrator, exact same issue**
The Mac goes through the upgrade process and shows the Mojave desktop with login. The first user to login (whoever they are) sees another black screen come up saying 13 minutes remaining. After that process completes then they can login to Mojave.
This is unacceptable for all the obvious reasons.
I have exchanged 15 messages and had two phone conversations with Jamf support, I've submitted two sets of different logs, and after two weeks I hear back that according to their in-house Mojave expert, this is expected behavior.
I am beyond frustrated, not only that but there have been at least 3 other issues of a simple nature that they either took forever to get back to me on or were simply unable to resolve.
If anyone out there has an answer or a simple way to accomplish upgrading Mojave, please, please let me know. 🙂
Munki is free and you know what if I need to spend time on message boards and use third party solutions and dig around github for solutions, why am I paying Jamf?????
Here's an update: This morning I checked on a teacher computer that I set to upgrade overnight, however, since the computer was asleep it didn't run. After manually running it, it took 34 minutes to complete the upgrade. After logging in I got the same "About 13 minutes remaining" (It only took about 3-4 minutes though, the last few minutes counting down in seconds.) After that it went back to the login screen with the password field empty.
An additional point of concern is that the same process has occurred when doing a within version upgrade 10.14.2 to 10.14.3 (I'm doing some more testing on this and will report back.)
@tnielsen Thanks for offering to help, very nice of you! Over a two week period I tried installing the upgrade through two different packages and policies, through VPP and policy, as standard user doing a manual download and install, and as a local admin user doing a manual download and install. I also tried on HDD, Fusion Drive, and SSD macs. In addition, I googled extensively on the issue, consulted colleagues, search Jamf Nation for discussion threads, and of course called Jamf support and provided them with logs from several different Macs. I feel satisfied with my due diligence 🙂
Speaking of Jamf support, I do want to add to the record that my account rep called me and we had a really positive discussion and the lead technician emailed me about the support process I had experienced so far. At this point, I am happy with their support and responsiveness. I used to manage a helpdesk and am sensitive to the challenges of offering support and am not quick to complain, I also understand that we are all (hopefully) always looking to learn and grow and do better, myself included.
@kroberts1 My colleague who has not seen this issue at all uses Munki and simply did the following for his upgrade: Munki import and then entered the path to specifying the location to the .app file and made it available through Managed Software Center.
Something I've noticed this morning is that the login followed by "X minutes remaining" problem only seems to happen for me when a user was logged in since the last reboot. I have a reboot policy setup to run between 3am and 5am, and then a startup triggered policy to run the update during the same window, and the whole process completed without needing to login. I haven't tested with a High Sierra to Mojave upgrade yet, but in a 10.14.3 to 10.14.4 update, the reboot/startup triggered policies skipped the login issue, but running the update through Self-Service did not.
Edit: The trick didn't work going from 10.13 to 10.14
Is this possibly the difference between Macs that have FileVault enabled and Macs that do not? Maybe the FileVault login screen is preventing the OS from being able to complete the required installs because it is halting the loading and decrypting of the hard drive? Just a thought.
I didn't read through all the responses for this, just most of them. Not sure if someone already mentioned this, but what I have done as a workaround is:
I create a auto-login user and deploy that with the download of Mojave or high sierra installer dmg. I kick off the install with Startosinstall command and parameters as mentioned above.
Then I have another policy scoped to a smart group "machines with auto login user" With a script that checks to see if the current user logged in is the auto-login user, if it is, it deletes that user then reboots the computer. I set that policy to on-going, frequency is reoccurring check in, scope it to that group as well as limit it to the auto-login user.
This allows the "installation completing: 13 mins remaining" continue with no issue or interaction by a user.
This is just a workaround I have currently to make the in-place upgrade "automated".