Posted on 09-21-2016 03:22 AM
I've read a lot of questions asking how to block upgrading to Sierra. Im more interested in what people might be thinking in how to get it deployed as fast as possible over the air.
Incremental OS updates, such as from 10.11.5 to 10.11.6 can be triggered through the software update payload of a policy. At this stage Sierra doesn't appear in the updates tab of the app store so it's understandable that nothing is happening currently. I wonder if when it does appear there it will automatically install from a policy in the same was as incremental updates. Have to wait and see I suppose.
Does anyone have any plans or particular strategies that they expect to use to update Sierra across their networks?
Posted on 09-21-2016 03:49 AM
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.
Posted on 09-21-2016 04:47 AM
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.
Posted on 09-21-2016 05:21 AM
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.
Posted on 09-21-2016 05:29 AM
Thanks for the bit on specifying the startup disk. I intend to try this out tomorrow.
Posted on 09-21-2016 05:47 AM
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.
Posted on 09-21-2016 06:36 AM
i have used my VPP to deploy via self service , i am going to try and extract the installer and use the DMG
Posted on 09-21-2016 06:39 AM
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/
Posted on 09-21-2016 06:53 AM
^ 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.
Posted on 09-21-2016 07:17 AM
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
Posted on 09-21-2016 03:13 PM
@casareanderson - I've done mine in two stages:
For Upgrades:
For Imaging:
Posted on 09-29-2016 12:08 AM
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
Posted on 09-29-2016 12:13 AM
Hi @Kennedy
Try the following settings, sorry mobile screenshot as I'm on the move.
Sachin
Posted on 09-29-2016 12:37 AM
Thanks, tried that and i get "/OS X Install Data is not a directory"
Posted on 09-29-2016 12:39 AM
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
Posted on 09-29-2016 12:43 AM
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...
Posted on 09-29-2016 02:55 AM
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
Posted on 09-29-2016 02:59 AM
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!
Posted on 11-18-2016 07:16 AM
This script got the upgrade working
bless -mount "/Volumes/macOS Install Data" -setBoot
shutdown -r now
Posted on 12-26-2016 09:49 AM
@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.
Posted on 02-16-2017 07:19 AM
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
Posted on 05-23-2017 07:48 PM
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