Yosemite in Self Service

The line

OS X Installer is for 10.10. Must be 10.7 or later to deploy it as an upgrade

- Justin

Could it be because I am on JSS 9.22 and deploying Yosemite would not be possible unless I upgrade?

I was able to successfully deploy Yosemite as an upgrade from Self-Service following the directions here.

http://resources.jamfsoftware.com/archive/Deploying-OS-X-v10.7-or-Later-with-the-Casper-Suite.pdf

Occasionally I have to force the policy cache or trigger using the command sudo jamf policy -id but the upgrades have been successful.

I'm currently using 9.51 in my production environment.

I also include a quick script that executes before the install that makes sure Journaling is enabled as i have seen an occasional drive that it was not enabled, and this fixes that so the installer doesn't lose its mind.

--M

@BellMedia I was also getting this until I upgraded the JSS. All works fine now.

I'm thinking it's definitely an old JSS issue, I have followed the attached guide with no luck. I'll report back after my upgrade.

Hm. Our JSS is running 9.52 and I just dragged the Install OS X.app into Casper Admin and it's been working fine. Had a handful of users use it rather than using the App Store. Only problem I saw was a remote user trying to run the policy and it failing out because JDS.

I'm seeing a totally different issue. I'm currently testing methods to complete the in place upgrade. I followed the instructions to from JAMF and get the following from the JSS.

Not exactly sure where things are going wrong.

@pbetancourth][/url If your issue with the Self Service way of doing the upgrade from a cached copy is that it won't restart into the upgrade process (i.e.. you run the install from cached package policy and nothing happens), make sure your restart options in your policy are set to an explicit restart, not "restart if package requires it" for both logged in and logged out options.

I'm also seeing what @pbetancourth is seeing. I was able to to run the installers in 9.6 fine. I got the alpha group upgraded (IT tests first for any package support issues) and then we did the 9.61 upgrade. After that i can get it to cache but it won't do the install properly.

@chriscollins if the issue is the same as mine, It ges through the motions but doesn't initiate a restart and doesn't run the installer on a forced restart.

I also do not see Yosemite as a package in Casper remote for testing cache and install cache. And when i use Casper remote to "Install all cached Packages" it shows the same behavior as Self Service.

In my environment, we also had to set the Startup Disk to OS X Installer in the policy's restart options.

I'm seeing this behavior on JSS 9.5. I've created a SS policy that downloads and installs the OS X installer DMG. It seems to run thru all of the appropriate steps and even restarts the Mac after it completes. But then it just boots up normally without running the installer. I've got the restart settings set to "OS X Installer" and restart immediately.

I don't know if this is still the case but the method in JAMF's article requires the user to have admin rights to install the upgrade. An alternative method that I use which can be ran via Self Service with a standard user account is to create an installation pkg using createOSXInstallPkg (https://github.com/munki/createOSXinstallPkg).

The one caveat with this is that if FV2 is enabled the user has to enter their password during restart to continue the installation.

@nixon85 It's not the case that the user has to have admin rights. Self Service runs as root, so it should definitely work, and it does. I think there's an issue with the macbook that i'm testing this on as it just worked on another Mac.

@denmoff ok will test it out. When I tried with previous OS versions the OS X Installer itself required the admin credentials to perform the installation, perhaps this has changed.

@nixonc85 How are you setting up self service installs, are you caching and running the installer via self service, or are you having it place the installer in Shared and then auto start the installer OS X.app?

It shouldn't require users to have admin rights when running packages through self service. We have Zero admin users in our division and one admin account that is used by casper and used by us to screen share with our users. It's because of Self Service that we have been able to create a "store front" for easy repairs, installs and uninstalls. and since the Kernel Swapping concept in OS X was put in place OS Upgrades have been a cake walk in Self Service. Still no clue on my what hiccup is causing my issue though..

@exno the penny just dropped... when I was trying this last year I was running Casper 8, I believe this behaves differently in Casper 9 so it is likely the createOSXInstallPkg method is no longer required. I'll try it out and stop talking nonsense now...

@nixonc85 no worries lol. Casper 9 is a beast with its on special needs too. it wasn't till 9.22 that upgrades actually worked through self service for me. and I'm glad it did. the end of imaging was something i needed to work if i wanted to scale the support we offer with our small team. Between Provisioning workflow for new and redeployed machines, OS upgrades (less problematic thanks to kernel swapping) via self service, and a move to SSD. i have been able to simplify the workflow and lessen end user interruptions greatly.

@pbetancourth I just had a machine restart from software updates and it load right into 10.10.1 for the machine that is saying it installed but not showing 10.10, try shelling in and running software updates.

I'v been able to do this upgrade in self service just fine in 9.61, but I just upgraded to 9.63 and now I get the "OS X Installer is for 10.10. Must be 10.7 or later to deploy it as an upgrade." in the logs and it just doesn't continue. This is using the same policy and packages I have been using all along.
I'v only tried it on 10.9.5 machines so far, but those are the majority that need it.
Has anyone found the cause for the misidentification of the OS by the installer?

We're seeing the same behavior, trying to upgrade to both 10.10.1 & 10.10.2 we're getting the same message ("OS X Installer is for 10.10.2. Must be 10.7 or later to deploy it as an upgrade.") in the jamf.log

This worked fine on 9.62, but it does seem to be a bug in 9.63.

Does anyone know of a workaround?

My JSS is v. 9.6.3

I dragged my Install OS X Yosemite.app into Casper Admin as is, which converted to "Install OS X Yosemite.InstallESD.dmg"
I just tried my Self Service upgrade on a 10.9.5 client (no admin password needed)
First policy just finished caching the .ESD and triggered 2nd policy which successfully booted to Yosemite installer.
I'm heading out but I think it would have failed before this if it was going to...still has 44 minutes to go installing
TGIF
Sandy

Yes, Sandy you're past where we are seeing issues.

I also dragged into Casper Admin 9.63 and it converted to "Install OS X Yosemite.InstallESD.dmg"

Caches fine, but the "install from cached" policy fails with this:
OS X Installer is for 10.10.2. Must be 10.7 or later to deploy it as an upgrade.

The Yosemite installer was downloaded from a Mountain Lion machine.
This is happening on both 10.8.5 and on a machine that I manually upgraded from 10.8.5 to Mavericks.

Will do more digging on Monday, but this was working fine for us on 9.62 so I can't get past feeling that it's an issue with the version check introduced in 9.63.

i'm pretty sure i downloaded the Yosemite installer to a mavericks computer... For what it's worth :)

Ended up trying multiple iterations of the Yosemite installer, downloaded from 10.8, 10.9, 10.10 - using the "Drag Yosemite Install.app" method into Casper admin with no luck.

We did get this from JAMF support: "We are not seeing this extensively and it took a very, very long time to reproduce, but after working pretty extensively, we've identified a change that we need to make in relation to how the install.esd is handled - it basically creates for itself it's own blessed folder and boots itself out of that folder to upgrade the OS. Due to some recent changes (which are being looked at as we speak) we've filed this as a defect: D-008322 and are working to remedy the issue ASAP. I do not at this moment have a timeline, but it will be sooner than later."

They later provided this workaround, which we tried in Casper Admin 9.62 & 9.63 but didn't help (I'm posting it here in case it helps someone else):

"So the workaround is to right click on the Install OS X Yosemite.app, click Show Package Contents, navigate to Contents/Shared Support and drag InstallESD.dmg to Casper Admin. When that’s done loading, then set the priority to 1 and check the “Requires restart" flag under “Options". Then click the General tab and check “Item is a DMG with an OS X Installer, or Adobe Update/Installer for CS3 or CS4” option. Then save it. Then create a policy with that new package or change the existing policy to use that one instead of the one created by dragging in the .app file."

We ended up going back to our old method - packaging the installer with the method suggested by @nixonc85 - and it works as expected.
https://github.com/munki/createOSXinstallPkg

Thanks, @Sandy, for testing & sharing your results. Sounds like this bug only affects a lucky subset of Casper admins :)

Hi,
Just a tag here that despite the fact that both policies ran "successfully" the computer I left on Friday did not upgrade to Yosemite. The computer did boot to the Yosemite install screen and when I left it sure looked like it was going, had 50 minutes to go....
My policy logs in the JSS both finished successfully. Guess I get to be Lucky too!!
Sandy