Hi All, Lets share idea's about how to upgrade to macOS Mojave via; Self Service App Store Others Also an idea to share idea's an how to upgrade from 10.14.1 to 10.14.2 due the new Software Update pane in Sysprefs. Cheers.

Jamf Pro; Upgrade methods for Mojave.

Hi All,

Lets share idea's about how to upgrade to macOS Mojave via;

Self Service

App Store

Others

Also an idea to share idea's an how to upgrade from 10.14.1 to 10.14.2 due the new Software Update pane in Sysprefs.

Cheers.

Page 2 / 5

This script works great when it works.

Maybe 50% of the machines I use it on that I upgrade from Sierra to High Sierra are getting errors like "nohup: can't detach from console: Inappropriate ioctl for device" or startosinstall works, machine reboots...no installer begins and it just boots back up to the current OS.

I wish there was a fully Jamf built in way.

In the enrollment process (user initiated) I as last step want to upgrade to Mojave OS(should be forced not self service). I have downloaded the 6gb installer and created a package in composer

But I have the following questions
1. What if the mac already have Mojave installed (is it possible to skip, so the client don´t need to download the 6gb package, as it is a bit waste of time if it is not needed)
DOn´t know what options there is to skip that step in enrollment

@jameson Just scope it to machines not on Mojave.

@kcsantos We have tried the in-place upgrade from High Sierra to Mojave with the edited script that you posted above. While the process no longer prompts for Admin credentials it seems to not remove them from the user when the process completes.

Begin the process from Self Service as a standard user, wait for the whole thing to finish, back to the logon screen. Login as the user; they are now an Admin on the Mac. The Admin rights that were given automatically to run through the process were not removed.

Anyone seeing similar?

I have a question, why would it not be feasible to simply download the installer from apple to the applications folder, then create a self service item to launch it normally. Which the user could then next next next next, through?

Our setup is fairly simplistic. We don't check for AC Power or battery level.

I created a .pkg with Composer that puts the macOS installer app in /Users/Shared. After that, we run the following script (not my script, but I can't remember I got it):

#!/bin/sh



macOSinstallerAppPath="/Users/Shared/Install macOS Mojave.app"



CurrentloggedInUser=$(/usr/bin/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 + "

");')



# There was an issue with startosinstall command that "Install macOS..app" needs to be opened once by logged in user to get it working properly

effectiveUserID=$(/usr/bin/id -u "$CurrentloggedInUser")

/bin/launchctl asuser "$effectiveUserID" sudo -u "$CurrentloggedInUser" /usr/bin/osascript <<EOT

        tell application "${macOSinstallerAppPath}" to activate

EOT

# Wait for 5 seconds to settle down then quit the app

/bin/sleep 5

/bin/launchctl asuser "$effectiveUserID" sudo -u "$CurrentloggedInUser" /usr/bin/osascript <<EOT

        tell application "${macOSinstallerAppPath}" to quit

EOT



# Run upgrade command

"${macOSinstallerAppPath}/Contents/Resources/startosinstall" --applicationpath "${macOSinstallerAppPath}" --rebootdelay 10 --nointeraction



# Reboot immediately if it has not rebooted by 'startosinstall'

#/usr/local/jamf/bin/jamf reboot -background -immediately



exit 0

@kcsantos We have tried the in-place upgrade from High Sierra to Mojave with the edited script that you posted above. While the process no longer prompts for Admin credentials it seems to not remove them from the user when the process completes.

Begin the process from Self Service as a standard user, wait for the whole thing to finish, back to the logon screen. Login as the user; they are now an Admin on the Mac. The Admin rights that were given automatically to run through the process were not removed.

@MTFMRCO - Good observation.I just noticed the same thing on my end, the Standard User who ran the upgrade has not been reverted back to a Standard User after. uggghhh... thought this was the solution! Back to more research on this policy.

@kcsantos @MTFMRCO I have this same problem as well; I am going to try running the script with the verbose flag to see if I can pinpoint the error and will get back to this thread. I observed that the ".demoteafterupgrade" token creates successfully , but the launchdaemons and the /usr/local/jamfps directory do not get created by the script for some reason.

We did the upgrade via Self Service as well. Created a Policy that cached the Mojave installer to any systems with an earlier version of OSX. Then created a Reimage Mac OS Policy and set it for Self Service only and leave it disabled until I want to upgrade a system.

by tnielsen
I have a question, why would it not be feasible to simply download the installer from apple to the applications folder, then create a self service item to launch it normally. Which the user could then next next next next, through?

@tnielsen - Our Users are local Standard Users and have FileVault 2 enabled. When a Standard user with FileVault2 enabled tries to run the script, they get the "osinstallersetupd wants to make changes" prompt which requires an admin password.

And yes, we have a pre-policy that caches the full macOS Mojave 6GB installer into the /Applications folder.

@arpierson -- Interesting... quick question: Are your users Standard Users with FileVault 2 enabled on the partition?

Interesting... quick question: Are your users Standard Users with FileVault 2 enabled on the partition?

@kcsantos Yes and no. Our users are Standard, but we don't utilize Filevault 2 as the vast majority of our devices are mobile labs that don't leave the building. Even teacher MacBooks aren't encrypted as we've found that they do such a poor job of backing up that Filevault just prevents us from doing data recovery and all of our sensitive student data is web-based, not stored locally. Since we don't use Filevault, I haven't encountered the "osinstallersetupd wants to make changes" prompt in my testing.

Hi All,

We are also looking into a in place upgrade from 10.13.3 to 10.14.x (x being the latest version available)

So for new machines we have a full DEP workflow that seems to be working pretty good, but i wont get into that unless people want to hear about it. I think i already did in another post (which i can link to if anybody is interested)

so for our Upgrade process...

In the Sierra to High Sierra upgrade we tested an in place using two Jamf Policies, first copies the App Store installer (Install macOS High Sierra.app) we pre stage that on machine a few days before the actual upgrade. Then we would send the second policy that basically ran the installer silently using the following script

#!/bin/bash



/Applications/Install macOS High Sierra.app/Contents/Resources/startosinstall --applicationpath "/Applications/Install macOS High Sierra.app" --rebootdelay 30 --nointeraction



#killall "Self Service"



exit 0

This process worked great. So i tested the same process for Mojave the script is as follows

#!/bin/bash



/Applications/Install macOS Mojave.app/Contents/Resources/startosinstall --applicationpath "/Applications/Install macOS Mojave.app" --rebootdelay 30 --nointeraction



#killall "Self Service"



exit 0

The upgrade works as well, but we ran into some weirdness and i cant find if anybody else that is seeing the same thing. It happens no matter if a user initiates the policy from Self Service or if i have it done on check-in over night.

The issue:

When i log in for the first time with a user (Mobile AD Account or a local admin account) the computer reboots and says 13 more minutes with an Apple Logo on a black background with the bar under it, (like a reboot during an upgrade) this wouldn't be that big of an issue with our faculty, but this cant happen in a fully automate lab install. Also we get a new Privacy Acceptance screen and the LIght vs Dark Mode (anybody have a way to suppress these two? light dark mode more important than the Privacy statement)

Is anybody else seeing this during an upgrade? I don't see this when i did a test directly from the App Store and clicking next, next ,next.

Very frustrating with all the new "features" and "security upgrade" in the OS. Its like Apple hates System admins and is trying to make our lives a living Hell every month =)

-Peter

@kcsantos
I would suggest writing a script to give the local user administrative rights during caching, then remove them after it's been detected the system is on 10.14.

I'll write the launchdaemon for ya, this was my idea about a month ago but I never had time to do it.

Hopefully these installation instructions will be of use to some of you. Obviously just change the High Sierra names to Mojave:

Upgrading to macOS High Sierra

Requirements
• A copy of Install macOS High Sierra.app from the Mac App Store
• Note : This has been tested on macOS 10.10.5, 10.11.5 & 10.12.5 upgrading to 10.12.6 and 10.13.3

• This script: https://github.com/kc9wwh/macOSUpgrade
• Jamf Pro Applications
o Composer.app
o Jamf Admin.app

Create a new Computer SmartGroup called High Sierra “Cached”
a. Criteria Tab
i. Application Title ‘has’ Install macOS High Sierra.app

Create a new Computer SmartGroup called High Sierra Ready
a. Criteria Tab
i. Operating System Version ‘is’ 10.10.5 OR 10.11.5 OR 10.12.5

Now we need to upload the Install macOS High Sierra Script from GitHub into the Jamf Pro Server:
a. Gear Icon > Computer Management > Scripts > Create new Script called macOS10.13Upgrade
b. Paste the contents of the script into the Script Tab
c. Save

Open Composer.app on computer that has a copy of the Install macOS High Sierra.app
i. NOTE: This step needs to be performed on a 10.12 or older machine that is still on the HFS filesystem. This is because an HFS file system can’t mount an APFS formatted DMG. If you make this on a 10.13 machine, it will format the DMG as APFS.
b. Drag the Install macOS High Sierra.app into the left side of Composer.
c. Build as DMG and place on the desktop
i. I named mine macOS High Sierra.dmg

Open Jamf Admin.app
a. Drag the macOS High Sierra.dmg we just made in Composer into Jamf Admin from the Desktop
b. Assign it a category and set it to a priority of 1
c. Save

Create a policy called “Cache” High Sierra
a. Configure Packages Payload
i. Select the macOS High Sierra.dmg package we just made in Composer
ii. Keep the “Action to take on computers” to Install

We are “caching” OR placing a copy of Install macOS High Sierra.app in the /Applications/ folder.
b. Configure a Maintenance Payload
i. Update Inventory
c. TESTING ONLY - Do NOT set a trigger
d. TESTING ONLY - Execution Frequency – Ongoing
e. TESTING ONLY - Make available in Self Service
f. Scope to group of TESTING computers that are not High Sierra.

- TESTING * - Open Self Service.app on one of the TESTING computers
  a. Run the policy “Cache” High Sierra
  i. This will place Install macOS High Sierra.app in /Applications
  ii. If that worked, move onto the next step. If it did not, then begin to troubleshoot.

Create a second policy called Upgrade to macOS High Sierra
a. Configure the Script Payload
i. Select the macOS10.13Upgrade script
ii. Enter /Applications/Install macOS High Sierra.app in Parameter 4
iii. Enter OS Version Number the machine is going to in Parameter 5
iv. Enter Customer trigger in Parameter 6 if applicable
b. Configure a Maintenance Payload
i. Update Inventory
c. Testing & Production - Do NOT set a trigger
d. Testing & Production - Execution Frequency – Ongoing
e. Testing & Production - Make Available in Self Service
i. Make sure you put in a disclaimer that the upgrade will take around 30-45 minutes and that Users should save all their work. Users will NOT be able to use their computer during this time.
ii. Check the box that makes the Users “View the disclaimer”
iii. Check the box that features the policy on the main page
f. Scope to Computer SmartGroup High Sierra “Cached”

If we can verify the “Cache” High Sierra policy places Install macOS High Sierra.app in /Applications and the Upgrade to macOS High Sierra policy executes the script that runs the macOS High Sierra installer, we can change the “Cache” High Sierra policy to:
a. Trigger – Recurring Check-In
b. Execution Frequency – Once per computer
c. Self Service – Uncheck box to remove from Self Service
d. Scope – Remove TESTING computers, and add High Sierra Ready Computer SmartGroup

@szultzie

You have filevault on I assume? That's why. The setup utility cannot unlock the volume for the user, the user must do it. There's no easy way around that I'm afraid. The users must wait.

@tnielsen No Filevault in my testing. But maybe your referring to someone else's scenario?

I get the following screen after an update is complete and i log in for the first time

then

and finally this

The last two im sure I can get around somehow, but i don't like that it reboots the computer after first log in, after an in place upgrade, I cant automate that for a Lab environment.

-Peter

@kcsantos @MTFMRCO Beware of copy/paste..check the code as pasted. I found by just pasting the script as is resulted in an issue with the plist not being created properly, Apparently there is a wayward space after the final EOL/EOF/EOP that is preventing the files from being created correctly and /bin/mkdir -p /usr/local/jamfps also contains a wayward space after jamfps

Running snippet in CodeRunner as pasted with space still present after EOP:

/bin/cat << EOP > /Library/LaunchAgents/com.apple.install.osinstallersetupd.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.apple.install.osinstallersetupd</string>
<key>LimitLoadToSessionType</key>
<string>Aqua</string>
<key>MachServices</key>
<dict>
<key>com.apple.install.osinstallersetupd</key>
<true/>
</dict>
<key>TimeOut</key>
<integer>300</integer>
<key>OnDemand</key>
<true/>
<key>ProgramArguments</key>
<array>
<string>$OSInstaller/Contents/Frameworks/OSInstallerSetup.framework/Resources/$progArgument</string>
</array>
</dict>
</plist>
EOP

Resulted in this output

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.apple.install.osinstallersetupd</string>
<key>LimitLoadToSessionType</key>
<string>Aqua</string>
<key>MachServices</key>
<dict>
<key>com.apple.install.osinstallersetupd</key>
<true/>
</dict>
<key>TimeOut</key>
<integer>300</integer>
<key>OnDemand</key>
<true/>
<key>ProgramArguments</key>
<array>
<string>/Contents/Frameworks/OSInstallerSetup.framework/Resources/</string>
</array>
</dict>
</plist>
EOP

Running again after removing the space from pasted code resulted in the EOP not being part of the plist

Has anyone worked into their workflow a good way to have the computer being upgraded get the necessary kernel extensions before the computer boots up with the new OS? I find that if I scope the Kext's to a smartgroup looking at a users OS, it most of the time is too late to the party and the user has already logged in and see's the warning messages.

I talked to JAMF support and they said it wouldn't work to push the config profiles to the computers before they're upgraded so somehow it needs to be done after the upgrade, but before the user logs in.

Curious how you all are doing it.

I'm currently testing the macOSUpgrade script and would like to use it if possible.

Hey @danshaw, maybe you can try this. It actually fixed a couple Config Profile failures I was having. A fellow MacAdmin on Slack suggested doing this:
-Create a smart group (named whatever) and as the criteria, have this:Profile Name Has Privacy Preferences Policy Control.
(My smart group has Last check in less than 15 days and that PPPC setting...that's it)

When a Mac upgrades to Mojave, that PPPC profile comes down automatically. I then scope that smart group to other config profiles I want, such as the whitelisting profiles we are all dealing with.
That PPPC profile group acts like a trigger to enable other profiles scoped to it to come down, see? So you could use that smart group as a target with your Kext Profile, so if it 1) upgrades to Mojave then 2) gets the PPPC profile (which it will), then whatever profiles scoped to that smart group get triggered.
I hope that helps. I have that workflow and it's not causing any issues.

We are also seeing the "osinstallersetupd" prompt, even using the newer script.

Any thoughts?

@billystanton29

I also got the prompt even if we do not run FV2 so I just edited the script so it gives admin rights to all users prior to the upgrade if they are not admins.

/usr/bin/dscl . read /Groups/admin GroupMembership |  tr ' ' '

' | grep -x "$currentUser"

if [[ $? -ne 0 ]] ; then

        /bin/echo "User is not an Admin.  Adding $currentUser to Admin group"

        /usr/sbin/dseditgroup -o edit -a "$currentUser" -t user admin

        /bin/echo "Demote token file added for $currentUser at $currentUserHomeDirectory/.demoteafterupgrade"

        /usr/bin/touch "$currentUserHomeDirectory"/.demoteafterupgrade

fi

@kcsantos @MTFMRCO

I have noticed that as well and found a solution.
The problem was that the LaunchDaemon is launched during startup as root and it cannot detect currently logged on user.
That is why I have added the part to finishOSInstall.sh at the start to check when the dock becomes active and then runs the rest:

while true; do

    myUser=`whoami`

    dockcheck=`ps -ef | grep [/]System/Library/CoreServices/Dock.app/Contents/MacOS/Dock`

    if [ ! -z "${dockcheck}" ]; then

        echo "Dockcheck is ${dockcheck}, breaking."

        break

    fi

    sleep 1

done

Hope that helps :)

I have two methods for this, but also run into the reboot problem faced by @szultzie

For a clean install on non T2 macs I use DeployStudio to image to the last version of 10.12.6, then install the Instal MacOS [Version}.app to /Applications and run startosinstall with --agreetolicense --nointeraction, I don't convert to APFS. This method works for Non-Fusion Macs but I converted them to APFS during the High Sierra update so this year I can use --eraseinstall

The other method I used was to Package the MacOS.app and script that, two policies for Fusion and non fusion scoped accordingly and installed by a common custom trigger. Now that Mojave supports APFS Fusion Drives they will get converted when upgraded so that's my 2020 vision, DeployStudio will be decommissioned and all builds will be (as close as possible to) zero touch DEP then JAMF'd.

The downside to --eraseinstall is that it will not run if the MacOS.app is older than the installed build, so you either need to keep your .app package updated or download it on the fly as per https://grahamrpugh.com/2018/03/26/reinstall-macos-from-system-volume.html.

FYI, guys the startosinstall "--applicationpath " variable has been depreciated in Mojave. I ran into issues when including that in the startosinstall command for Mojave. I also had to add a "--newvolumename" variable for the Mojave install as well.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded