I haven't had experience with the model yet, but have seen one report that the OS is forked....
I have been assuming it would be since it's using an updated discrete graphics chipset, which the 13" doesn't use....

Hive mind says "Yes"

Fork Youuuuuu Apple!

Yeah, not surprising. This is pretty much Apple's SOP these days. They have little to no interest in keeping a unified OS X build for more than a few weeks at a stretch it would seem. I would think forking the OS so frequently would make for a development nightmare, but what do I know?

Well, good news is that 10.10.4 isn't far off. So, time for a new base image...then wait two weeks for new hardware and repeat...

If only someone had helped with the faffing around when forked...

I'd hazard you might be able to get away with a functional system with the current build 11D136 with a base model 15, but there's a different dedicated video on the higher end models that would likely result in a kernel panic.

This isn't exactly new SOP for Apple. It's been this way for years now. And it usually lasts 2 months until a new combo update unifies the build.

@boettchs Yes, I'm thinking we may try to hold out for 10.10.4 and see if that brings things back together and go with that, especially since 10.10.3 has broken some important things for us anyway.

@mm2270 The guy that knows much about this - @nessts might have info on the latest .4 build. I have not tested that again, so I don't know if beta #3 nixed that or not...but it is a PITA for sure.

This is where @gregneagle chimes in to remind us we shouldn't be touching the OS. ;+)

I have not tested the latest seed for a fix createmobile, I have a fix built in my process anyway at this point, Apple has not replied back on the bug report I submitted, oh wait they have not replied back on the last 6 or the last 7 I have submitted. So, I have not expected any goodness to come from them any time soon.

you may want to wait for something better than 10.10.4 to come out too, I have had lots of unhappiness on this set of seeds. Of course what they release will have only so much to do with what we are testing I suppose since its been something like 3 years since the final seed matched the release version.

From IRC

donmontalvo @gneagle you're wanted in ER... https://jamfnation.jamfsoftware.com/discussion.html?id=14541
gneagle This is why people need a no-imaging workflow in their toolchest.
gneagle Boot the machine in TDM, install your bootstrapping pkgs, shut down. Connect to network, start up. Let your management system set the machine up to your standards.
donmontalvo Yep, been more open to it over the past few months.

cannot agree more, the base OS is important only for re-imaging a hosed machine. all new stuff should just be getting the custom stuff only.

I love the idea behind the no-imaging workflow and have been pushing for it more and more here, but unfortunately, its still a little simplistic to just assume it will always work correctly. If the stable of apps and tools you need on your Mac's is small or very basic, then yeah, it can work great. If you have a number of more, ahem, 'complicated' applications and tools, like AV software (MCAfee AV/Firewall), virtualization, VPN (AnyConnect for example) and other stuff like that which is mandated by the org or environment and which our users rely on daily, it means we can't just blindly accept whatever OS Apple decides to shove down our throats. The next point release could cause incompatibility issues with these apps, and the vendors aren't exactly super quick on updating their wares, which makes matters worse.
Another perfect example is the createmobileaccount binary getting busted with 10.10.3. We use that in a custom user setup process, so if we just took 10.10.3 and ran with it, a lot of remote users receiving Macs would have been dead in the water.
Then there is the issue of "re-images" which means we likely still need a base OS. Internet restores are still pretty painfully slow.

Believe me, I'd love to get away from imaging as a whole and just use the OS they ship with, and I fully expect we will get there, but so far what we've seen is that, at least in our case, its only trading one issue for another.

Has anyone posted a blow by blow of their workflow for thin imaging with Casper? I'd really like to not touch the OS moving forward and not deal with circumstances like this, but I'd like to see how other folks are automating this process so as not to reinvent the wheel.

How do you folks kick off the Casper workflow for setup? I haven't been able to wrap my head around how I get past the initial user setup and Casper enrollment part. Even with DEP, you'd still have to create a user... correct?

I would want all of my users to be created via policies (outside of the end user who would be created via mobile account creation via logging in with AD credentials). Really I want EVERYTHING to be handled via policies and Config Profiles. How do you we make this as no touch as possible? At least as no touch as Casper Imaging.

@hkabik for me, I utilize Casper Imaging on a NetBoot image to get the machine enrolled and to drop my first boot script that handles configuration and installation of packages via policies. Casper Imaging takes care of enrolling the machine and getting the initial management user on the machine so that I do not have to create a user on the machine.

For new machines out of the box, I scan their serial number into a Pre-Stage Imaging workflow in the JSS, boot the machine off the NetBoot Image, and then sit back and watch Casper Imaging auto launch and lay down the first boot script.

I'll beat @bentoms to the punch: My Casper Imaging Workflow

Ah, I was trying to get around a netboot/external boot disk all together. So as to avoid situations where new machines won't boot to previous netboots, such as when Apple forks us.

Thanks though, I'll definitely add your process to my list of possibilities. Really appreciate it.

@hkabik So create a user. In it's current form, yes you need to create a user during Setup Assistant. You can give the user a generic name which gets deleted upon next boot, and have Self Service automatically open for the tech who's binding the laptop to install another apps/printers/etc. In this situation everything is being driven by the JSS and not by the local imaging server or a technician's USB drive.

@mm2270 Well, if you look at it, there's two options. "Blindly accept" whatever OS Apple forces on the new model, or don't buy the new model. If you have apps that aren't compatible with the latest point release that is required on that model than no image/thin image/fat image isn't going to help you unfortunately. On the other hand, it's pretty easy to build a checklist to vet required apps on the latest OS release. You can do most testing in a VM, too.

I have my guys boot them to target disk mode, read the version of the OS off the disk before they touch it, if its one we don't have they capture an image of it then deploy the proper configuration without an OS in the configuration, through casper imaging. turn on the new machine.

Hence from above

gneagle Boot the machine in TDM, install your bootstrapping pkgs, shut down. Connect to network, start up. Let your management system set the machine up to your standards.

Mike,

Yes, we can "just blindly accept whatever OS Apple decides to shove down our throats". If you have to or want to use the new hardware you have to run the OS that it comes with.

I agree that there are many issues that make using the factory OS tricky. I think those of us that use the factory image are trying to point out is that, the sooner we all accept that we have to deploy on Apple schedule the better off we all will be...

It's all trade off for management, want to have the current hardware, well then we are going to have to change the image requirements.

C

PS What really gets me is that asking the 3rd party vendors to deploy on Apple schedule is not something unreasonable to ask. Jamf, Microsoft, Symantec and CrashPlan are just a few that have been on Apple schedule for over three years.

PSS. Now that I am on a roll I will go as far as saying it's our own fault, we enter in contracts with these vendors and don't write our requirements in the contracts!!

Yeah, look, I made it clear I don't love the way things are still being done, and I'm pushing for the change, despite its tricky challenges. Unfortunately, this decision isn't mine alone to make. Right now we are often forced to choose option 2 "don't buy the new model" (until we can support it) Honestly, no-one needs the new models the day after they ship anyway. This gives us some buffer to check on the new model and make sure we can work with it, or create a plan of action if it looks like it will give us some trouble.

Anyway, things are more complicated that they may appear in some places. All I'm trying to say is that those of you just saying everyone should work this way are being a bit dismissive to the realities of other environments that you know nothing about. Just as much as those of that still work the "old fashioned" way need to keep an open mind, the reverse is just as true. There is no such thing as one size fits all.

Mike,

Sorry if I was piling on, and sorry for being hostile, I didn't want it to be but after rereading I was !!!

Super sorry!!!

C

Chris, no need to be so apologetic. You did not offend. This is just one of those topics that brings out fevered debate on this issue (which is good honestly!) I'm not mad at anyone in particular. Partially mad at Apple for not being just a little more helpful in this regard, but more mad at the work environment that moves too slowly to adapt to these changes, and then we (engineers) get saddled with trying to figure out how to make a square peg fit a round hole and do it yesterday. The good news is, management is starting to get it here and are asking us to start thinking of how we can adapt our imaging workflow, so the time is about right to start switching to the better way of working. Apple sure isn't going to change their ways, so we're going to need to. But as things stand, these kinds of forked builds still... fork us over :)

@hkabik you can get the same results TDM the new machine and running Casper Imaging from the machine you are connected to. CI will enroll the machine and drop your first boot scripts, if you have any, and create your management user. Keeps you from having to run through Setup Assistant.