We - as a school - blocked it also to do the testing with the teachers first.

But if I would have to deploy it I would consider multiple solutions:

Caching server and let the teachers updgrade over the AppStore, works, maybe put a lot of load to your network. Some do it, some not - we dont realy care about.

Put the whole App to a dmg and just copy it over. Use JSS and your JDS (whatever solution) to distribute the Install macOS Sierra.app to the computers. Users can then open it and do the upgrade whenever they want.

The two policy way: extract the pkg from the app or build a upgrade pkg with your pkg-building solution. Test it not to overwrite the whole harddrive of target computers. Then you build a policy to cache the pkg on the computers - over selfservice or auto - its up to you. Than you have to build another policy to trigger the installation of cached packages. Advantage: you can set multiple groups (smart or not) to upgrade in smaller numbers or by division, ect. And you can date the last policy to time and date you figured out with the users. Important: last policy needs to run on a startup or shutdown hook and the users should be informed that starting or shutdown takes a long while and they shouldnt power down the computer by themself.
If your computers are only stationary you can use the last option more easily by telling the users to let their computer on while they are leaving in the afternoon.

At school we do it the first way because the teachers sometime decide to do such upgrades at home or the IT Helpdesk do it by reimaging the whole computer.

Is a 2 policy way actually necessary? Could you not have a policy that is set to cache the pkg you built, a maintenance task that installs all cached packages and a restart options specified to restart in a few minutes? Maybe that doesnt work for OS upgrades specifically i have never tried it.

I guess if you auto cache it on everyones computer and just have the self service button kick off the install it will appear to them to go much faster.

I can see cases for distributing the .app too. That simplifies the process a bit for users but they of course still need to take some action on it.

I guess another benefit of building a policy/policies like that is you can use the same process for iMacs overnight.

I also wonder if its safe to try trigger all this to automatically happen at night or something without the user instigating it.We have regular OS updates, including those that require restarts, scheduled to automatically be applied in certain time frames and that has never caused any issues.

Some users have already upgraded. Sierra presents a lot of features that the average user is excited for so perhaps we will find that the majority do it from the app stores themselves, perhaps thats too optimistic though.

Many here have used this process, I've used it for the last two major versions, expecting to do so again with 10.12 via Self Service.

Use createOSXinstallPkg to generate a Sierra .pkg

Scope that package to whatever groups you want, and make sure you set the Restart Options to: Startup Disk: OS X Installer and restart immediately.

Search around here for createOSXinstallPkg and you'll find a lot of similar discussion.

Thanks for the bit on specifying the startup disk. I intend to try this out tomorrow.

All I did was cache the install on all users and created an install in self service. We haven't had any problems so far.

i have used my VPP to deploy via self service , i am going to try and extract the installer and use the DMG

I'm using a Self Service-provided upgrade for Sierra (went live yesterday) which leverages a createOSXInstallPkg-generated OS installer. For more details, please see the link below:

https://derflounder.wordpress.com/2015/11/23/providing-os-x-upgrades-via-caspers-self-service/

^ Actually I read your post on the matter previously and re read it today. Wasnt sure if anything had changed with Sierra but based on what everyone is saying it hasnt. That gives me confidence it will work.

I had a thought of deploying via VPP self service. I could see that being particular useful if you dont have the distribution infrastructure for the package yourself and you dont want users, or dont allow them, to make their own Apple IDs to 'purchase' it.

i used VPP and it worked fine , i am just testing to down load the VPP and extract the DMG and place that in self service

@casareanderson - I've done mine in two stages:

For Upgrades:

1. Downloaded the macOS Sierra public build from the AppStore, drag the full installer into Casper Admin 9.96, Casper Admin already knows that it's an OS X Installer, create a self service policy for the users, (if you're serving it from a local DP then i'd limit the policy to those network segments), with an OS X Installer Reboot configured. Have two smart groups, one that finds all macOS Sierra machines eligible to upgrade as the scope and the other smart group which finds all machines that have macOS Sierra already and exclude this from the Upgrade policy.

For Imaging:

1. I used AutoDMG to make a DMG of macOS Sierra and then AutoCasperNBI to make the new netboot environment (not necessary, I like consistency!). Uploaded the macOS Sierra dmg to Casper Admin placed it in my build configuration. Uploaded the macOS Sierra netboot image file onto my local distribution points.

Hi all,

I notice that the install data for Sierra is located at "/macOS Sierra Install Data"

The OSX Installer reboot option looks for "/OS X Install Data"

I have tried the following settings, but the machine fails to reboot, despite alerting the using that the machine will reboot.

If we restart manually, the macOS Sierra Installer kicks in, so it's just the rebooting part of the policy we'd like to get going.

Any thoughts out there?

Cheers,
Gav

Hi @Kennedy

Try the following settings, sorry mobile screenshot as I'm on the move.

Sachin

Thanks, tried that and i get "/OS X Install Data is not a directory"

Did you package the macOS Sierra installer or drag and dropped the public installer from App Store into Casper Admin?

Also do you have FileVault configured?

Sachin

No FileVault, and I packaged it using createOSXInstallPkg.

The package works correctly - dumps everything to the "/macOS Install Data" directory on the volume, and when the machine is restarted the installer kicks off.

Its just the reboot that isn't working.

I'll try dragging the installer into casper admin and see how I go...

Turns out a standard reboot with no bless works fine - setup kicks in after reboot. Whoops!

Our process is simple:

1) Create the package with createOSXinstallPkg.
2) Zip the .pkg file and upload to Casper Admin.
3) Create a policy to cache this package to computers you want to upgrade.
4) Create a Smart Group for computers that have the package cached.
5) Scope a Self Service Policy to the above smart group.
6) Advise users to install when they have a spare 30 mins.

I would like to run a policy (mainly just a recon to pick up the new OS version) on startup after the installer has complete. Does anyone have any clever solutions to achieve this?

Cheers,
Gav

Clearly not thinking straight tonight. I can just create a breadcrumb as part of the install cached policy, and scope my startup policy to machines with that breadcrumb. Whoops!

This script got the upgrade working

!/bin/bash

bless -mount "/Volumes/macOS Install Data" -setBoot
shutdown -r now

@Kennedy wrote:

If we restart manually, the macOS Sierra Installer kicks in, so it's just the rebooting part of the policy we'd like to get going.

From the GitHub page:

The next step would be to reboot, but the postflight script does not do this; it just exits. The package is marked as requiring a reboot, so whatever mechanism is used to install the package is responsible for rebooting as soon as possible after the install.

We are on 9.92 (at least until the dust settles on 9.97), and while issuing reboot command the end of the policy works, doing that gives me the heebie-jeebies.

First policy caches the installer.

Second policy runs the cached installer.

Here is what the log shows for that policy:

We do have [x] Requires restart set for the createOSXinstallPkg generated package, but JSS doesn't seem capable of rebooting once the install is complete.

We are also using installosxpkg_postflight which accommodates the macOS mount point (lines 63-69).

For running inventory after the reboot, we'll probably run jamf recon as root via a run once Launch Daemon.

Hi ,
while caching the Mac os sierra installESD.dmg i get a below logs under Jamf.log

cp: /Volumes/CasperShare/Packages/Install macOS Sierra.InstallESD.dmg: Device not configured
cp: /Volumes/CasperShare/Packages/Install macOS Sierra.InstallESD.dmg: could not copy extended attributes to /Library/Application Support/JAMF/Waiting Room/Install macOS Sierra.InstallESD.dmg: Socket is not connected.

I can see the waiting room has the installESD.dmg and installESD.dmg,cache.xml

When I had issues upgrading to macOS Sierra through Self Service, I have contacted JAMF and was given the following link.I tried and It worked for me. Hope it helps. https://github.com/kc9wwh/macOSUpgrade