Yosemite in Self Service

[BellMedia]

Just curious how others are deploying Yosemite through Self Service. I tried the standard method we used for 10.7 and 10.8 listed here:
https://jamfnation.jamfsoftware.com/article.html?id=173
But unfortunately it fails for me: Tue Oct 21 14:07:57 ag-ctslab-111 jamf[7648]: Executing Policy Install Yosemite...
Tue Oct 21 14:07:57 ag-ctslab-111 jamf[7648]: Installing Install OS X Yosemite.InstallESD.dmg...
Tue Oct 21 14:07:59 ag-ctslab-111 jamf[7648]: Preparing for in-place OS upgrade...
Tue Oct 21 14:08:04 ag-ctslab-111 jamf[7648]: OS X Installer is for 10.10. Must be 10.7 or later to deploy it as an upgrade. Tue Oct 21 14:08:05 ag-ctslab-111 jamf[7648]: Blessing in-place OS upgrade directory...
Tue Oct 21 14:08:11 ag-ctslab-111 jamf[8000]: Reboot. 10.4+. Background.
Tue Oct 21 14:08:11 ag-ctslab-111 jamf[8000]: Adding launchd task to reboot...

Any thoughts?

[justinrummel]

The line

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

is very odd... as if you were running this on a 10.6 machine.

- Justin

[BellMedia]

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

[danielc29]

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.

[MarkMelaccio]

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

[sinergi]

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

[BellMedia]

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.

[emily]

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.

[pbetancourth]

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.

[chriscollins]

@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.

[exno]

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.

[wubbelsl]

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

[denmoff]

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.

[nixonc85]

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.

[denmoff]

@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.

[nixonc85]

@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.

[exno]

@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..

[nixonc85]

@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...

[exno]

@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.

[AdamH]

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?

[Shane]

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?

[Sandy]

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

[Shane]

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.

[Sandy]

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

[Shane]

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 :)

[Sandy]

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

[AdamH]

I'v been working with JAMF on this issue and got the same work around- using the InstallESD.dmg. However using that gave me the same results as before.

[tcandela]

does anyone know if changing the name of the downloaded installer app from "Install OS X Yosemite.app" to "My dept OS X Yosemite.app" PRIOR to dragging it into Casper Admin have a negagtive effect on its conversion to "Install OS X Yosemite.InstallESD.dmg" ?

[Sandy]

Update on this:
I upgraded to JSS 9.6.4
Re-downloaded the Yosemite Installer from App Store on a Mavericks computer
Dragged the full installer into Casper Admin, checked box for apple OSX installer, set priority 1
Updated my Self Service policies: first one caches this package and then sends custom trigger to 2nd policy
Second policy installs the cached package, set policy to restart to the installer and restart immediately (both)

Worked! (previous attempt using full installer went through ALL steps including booting to installer but never installed 10.10. Workaround using the install.esd resulted in the weird errors above as though it were a 10.6 computer)

Wrinkles: I downloaded the Yosemite installer on the actual model that I then ran the self service policy on
I am not 100% sure I deleted the original installer from the computer after putting it up to Casper Admin edit:
Same computer, re-imaged back to 10.9.5, then ran Self Service policy, now no worky and getting the weird must be at 10.7 error. Wondering if that installer was still in the apps folder, and the second policy somehow called the actual original installer.... hmmmm... back to the drawing board

[chlaird]

Chiming in with the same results as @Sandy][/url. 9.64 did not resolve the error, we continue to have the 10.7 issue.

[AdamH]

Yeah, I'm having the same problem as well. I tried both the InstallESD workaround as well as the direct copy from the App store.
I did some fooling around and got it to work, but I tried so many things, including removing the framework, that I have no idea how it worked.
But 9.64 didn't seem to be the fix.

[chris_hansen]

Check that the computer to be upgradedn registers as MDM capable.

I just today experienced this, using JSS 9.63
This Mac was upgraded from 10.6 to 10.9.5 using Self Service.
I tried to use Self Service to upgrade to Yosemite, same method.
Then I encountered the "OS X Installer is for 10.10. Must be 10.7 or later to deploy it as an upgrade" message in the policy log.
Weird, since I have used this ESD in a policy successfully on other Macs.
I took a look at the Machine stats and noticed it wasn't MDM capable.
I re-enrolled it, then reconned it, and it came up as MDM capable, and then the installer worked. I did not remove the framework first.

[donmontalvo]

JSS 9.63, uploaded latest Yosemite installer.

Created Smart Group (Is Like 10.9).

Policy to cache Yosemite installer (disabled Restart Options since we are only caching) to above Smart Group.

Smart Group created (Is Like 10.9 and Has Yoyo Installer cached)

Self Service policy scoped to above Smart Group (set Restart Options to boot into installer)

Confirmed update completes without issue, hidden accounts okee dokee.

EDIT 2015-04-30: If you don't have a visible account on the Mac, you'll be prompted to create an account; keep this in mind if you're hiding your JAMF management account.

[MarcosMunoz]

@donmontalvo - I followed those steps. But, I am required to interact with the installer and setup a new account during the installation.

Once I go through it, all of my previous data, accounts and settings are still there.

But, I don't like the fact that the users will have to go through the installer as if it were a new machine.

Is there a way to upgrade the OS without having to go through the setup?

BTW, I am going from 10.9.5 to 10.10.3.

Thanks!

[donmontalvo]

@mmunoz2 We're using this to upgrade existing 10.9 users to 10.10.

If you're doing new Macs, why not drop a non-booted Yoyo image onto it (AutoDMG, JSS, etc.)?

PS, say hi to Nestor Menar (NYC) for me. :)

Don

[MarcosMunoz]

@donmontalvo Hey Don. What you are doing is exactly what I am attempting to replicate. However, after the machine boots into the cached Install OS X Yosemite.InstallESD.dmg, it treats it as a new machine rather than an upgrade and I am forced to interact with it. I must be missing a step. For all new machines, I simply image them with Casper Imaging and a dmg created with AutoDMG. Thanks.

[donmontalvo]

@mmunoz2 if the Mac has already been booted, and has the jamf management account, it shouldn't prompt you to create a new user. Our testing shows user just needs to OK the installer, once its done there's one prompt for iCloud, then they get to the Desktop.

[MarcosMunoz]

@donmontalvo That's the baffling part. The machine has been booted into in order to launch Self Service and kick off the upgrade policy. It is managed so the management account does exist. Yet, it prompts to create a new user every time. Bizarre.

[donmontalvo]

@mmunoz2 if the management account is the only account on the Mac, and it is hidden, I'm not surprised that you are being prompted to create an account. ;)

[cindySingh]

It works successfully for me. I followed createosxinstallpkg by Greg and it seems working ok. I deploy as a pkg.