OEM discs for Thunderbolt all show 10.6.6 build 10J3210...

[donmontalvo]

We finally got a few of the new Sandybridge/Thunderbolt MacBook Pro laptops. All of them (MacBookPro8,1; MacBookPro8,2 and MacBookPro8,3) come with 10.6.6 (10J3210).

I generally take the least risky route when creating images, so to avoid any gotcha's we fork our build image development when new hardware comes out. The intent of course is to reunify once the next combo updater is released (10.6.7 in this case).

Just curious if anyone on this forum is going with only one image for all three of these new MacBook Pro models? If so, any issues?

Thanks,
Don

[donmontalvo]

That would be awesome, like gestalt/installer checks in packages.

[golbiga]

Don,

I've gone with one image (InstaDMG) for all the new MacBook Pros. And the I have an older InstaDMG image for the rest of my macs. No complaints here.

Thanks
Allen

[stevewood]

My opinion, you could create your image off of the 8,3 machine and use it
On Wed, Mar 16, 2011 at 10:13 AM, Don Montalvo <donmontalvo at gmail.com>wrote:
for every machine in your deployment, not just the new MBP machines. That
installer should have all hardware drivers for prior machines as well as the
new ones.

Just my opinion.

Steve Wood
Director of IT
swood at integer.com

The Integer Group | 1999 Bryan St. | Ste. 1700 | Dallas, TX 75201
T 214.758.6813 | F 214.758.6901 | C 940.312.2475

[golbiga]

There is only one build for all three so that should contain the drivers for all three models (8,1.8,2.8,3). Shouldn't matter which model you use to make the image.

Allen

[stevewood]

True, but I've always built my images on the highest machine I have in
On Wed, Mar 16, 2011 at 10:39 AM, <GolbigA at mskcc.org> wrote:
stock. So my assumption (since I don't have any of these) is that the 8,3
is the highest machine (17" MacBook Pro).

Just a carry over from the old days of building images for ASR.

Steve Wood
Director of IT
swood at integer.com

The Integer Group | 1999 Bryan St. | Ste. 1700 | Dallas, TX 75201
T 214.758.6813 | F 214.758.6901 | C 940.312.2475

[donmontalvo]

Makes sense, the disk image version might be another factor as well. Here's what I see for 13" and 15":
On Mar 16, 2011, at 10:53 AM, Steve Wood wrote:

13" MacBookPro8,1 10.6.6 (10J3210) OEM_Disc#2Z691-6796-A 15" MacBookPro8,2 10.6.6 (10J3210) OEM_Disc#2Z691-6806-A 17" MacBookPro8,3 10.6.6 (10J3210) OEM_Disc#<waiting-for-arrival>

Since the build number is the same across the board, I would assume the newest would be the 17" model. It'll be a week or two before those come in here. Until then I started making images for 13" and 15" models. I'll keep then separate for now, until we know for sure if one will be able to handle all.

Thanks,
Don

[donmontalvo]

Hmmm...would these be video related? One thought, will standard resolution units have different build than high-res units?

[#9]

Steve, I go the same route too although I have had some oddities like my
last build was on MacBook Al with 10.6.5 and that will also boot and run
Unibodies.

[#10]

That is possible although high res units are usually not a standard build
spec. Standard display configs tend to be purchased.

[jhalvorson]

I got burned once in the past by not forking, aka having a Special Edition
configuration for newer hardware. (It was a strange issue that would not
allow VMware to boot virtual machines on older hardware that used the newer
Mac OS X build.)

So until 10.6.7 is released, we are using a specific 10.6.6 configuration
for all Early 2011 MacBook Pro's. That requires me to warn the 7 people
that have access to Casper Imaging about the special config. FEATURE
REQUEST - allow Casper Imaging to post a message after launching!!!

Example of our configs:

=Enterprise 10.6.6 MacBook Pro Early 2011 (Parent config, no smart config)
=WSS Prod 10.6.5 OS and Std Apps (Parent config, with the following smart
configs)
- Enterprise 10.6 iMac or mini
- Enterprise 10.6 iMac or mini with iWork
- Enterprise 10.6 Laptop
- Enterprise 10.6 Laptop with iWork
- Enterprise 10.6 Mac Pro
- Enterprise 10.6 Mac Pro with iWork

Jason

[bentoms]

I requested a feature request like this in 2010 london ccna.

Basically as we have "only install if processor is..." I'd like "only install if model is..."

Casper imaging does check processor by getting a system profile report. So should be easy.

Regards,

Ben Toms

[donmontalvo]

We just followed the JAMF process for creating BaseImage and NBI, so we now have a forked image development tree:

BaseImage_1065_10H574 <-- standard for all Intel BaseImage_1058_9L30 <-- standard for all PowerPC BaseImage_1066_10J3210 <-- TEMP for MacBookPro8,1 13" ONLY BaseImage_1066_10J3210 <-- TEMP for MacBookPro8,1 15" ONLY BaseImage_1066_10J3210 <-- TEMP for MacBookPro8,1 17" ONLY

NetBoot_1065_10H574 <-- default NetBoot image for Intel NetBoot_1058_9L30 <-- default NetBoot image for PowerPC NetBoot_1066_10J3210 <-- TEMP for MacBookPro8,1/2/3 (tech uses OPTION key at boot to select NetBoot image)

So our previous images stay the same for the time being. And for the new models, we're not taking chances, time to create BaseImage and NBI is less than having to deal with issues (proactive vs reactive).

Also it allows us to prepare for a Late-2010-iMac fiasco where we had to scramble and take steps back on image development because of a curve ball tossed to us by Apple.

What was that old Bush quote...

Thanks,
Don

--------------------------------------------------
"There's an old saying in Tennessee — I know
it's in Texas, probably in Tennessee — that
says, fool me once, shame on — shame on you.
Fool me — you can't get fooled again."
— George W. Bush, Nashville, Tenn., Sept. 17, 2002
--------------------------------------------------

[donmontalvo]

(sorry...corrected the names of the 3 temp BaseImage images. Don)

We just followed the JAMF process for creating BaseImage and NBI, so we now have a forked image development tree:

BaseImage_1065_10H574 <-- standard for all Intel BaseImage_1058_9L30 <-- standard for all PowerPC BaseImage_1066_10J3210_13 <-- TEMP for MacBookPro8,1 13" ONLY BaseImage_1066_10J3210_15 <-- TEMP for MacBookPro8,1 15" ONLY BaseImage_1066_10J3210_17 <-- TEMP for MacBookPro8,1 17" ONLY

NetBoot_1065_10H574 <-- default NetBoot image for Intel NetBoot_1058_9L30 <-- default NetBoot image for PowerPC NetBoot_1066_10J3210 <-- TEMP for MacBookPro8,1/2/3 (tech uses OPTION key at boot to select NetBoot image)

So our previous images stay the same for the time being. And for the new models, we're not taking chances, time to create BaseImage and NBI is less than having to deal with issues (proactive vs reactive).

Also it allows us to prepare for a Late-2010-iMac fiasco where we had to scramble and take steps back on image development because of a curve ball tossed to us by Apple.

What was that old Bush quote...

Thanks,
Don

--------------------------------------------------
"There's an old saying in Tennessee — I know
it's in Texas, probably in Tennessee — that
says, fool me once, shame on — shame on you.
Fool me — you can't get fooled again."
— George W. Bush, Nashville, Tenn., Sept. 17, 2002
--------------------------------------------------

[donmontalvo]

(sorry...corrected the names of the 3 temp BaseImage images. Second typo...need more coffee....Don)

We just followed the JAMF process for creating BaseImage and NBI, so we now have a forked image development tree:

BaseImage_1065_10H574 <-- standard for all Intel BaseImage_1058_9L30 <-- standard for all PowerPC BaseImage_1066_10J3210_13 <-- TEMP for MacBookPro8,1 13" ONLY BaseImage_1066_10J3210_15 <-- TEMP for MacBookPro8,2 15" ONLY BaseImage_1066_10J3210_17 <-- TEMP for MacBookPro8,3 17" ONLY

NetBoot_1065_10H574 <-- default NetBoot image for Intel NetBoot_1058_9L30 <-- default NetBoot image for PowerPC NetBoot_1066_10J3210 <-- TEMP for MacBookPro8,1/2/3 (tech uses OPTION key at boot to select NetBoot image)

So our previous images stay the same for the time being. And for the new models, we're not taking chances, time to create BaseImage and NBI is less than having to deal with issues (proactive vs reactive).

Also it allows us to prepare for a Late-2010-iMac fiasco where we had to scramble and take steps back on image development because of a curve ball tossed to us by Apple.

What was that old Bush quote...

Thanks,
Don

--------------------------------------------------
"There's an old saying in Tennessee — I know
it's in Texas, probably in Tennessee — that
says, fool me once, shame on — shame on you.
Fool me — you can't get fooled again."
— George W. Bush, Nashville, Tenn., Sept. 17, 2002
--------------------------------------------------

[bentoms]

Looks like the 10.6.6 shipping with the new MacBooks has some issues with displays & home sharing: http://www.macrumors.com/2011/03/17/2011-macbook-pros-experiencing-issues-with-home-sharing-in-itunes/

Regards,
Ben Toms
IT Support Analyst GREY Group
The Johnson Building, 77 Hatton Garden, London, EC1N 8JS
T: +44 (0) 20-3037-3819 |  Main: +44 (0) 20 3037 3000 | IT Helpdesk: +44 (0) 20 3037 3883

[donmontalvo]

We tell all our "It's new and I gotta have it now!" users who get the new MacBookPro8,1/2/3 laptops that they'll be getting a "Pre-release" build. So they know if they have any issues, they'll get best-effort support.

Two ideas we're pondering. If a user calls for help after we have reunified (10.6.7) our build, two possible scenarios. First option, apply the 10.6.7 combo updater (this should save tons of time for the tech and user). Second option, reimage using our unified (10.6.7) build (we have a migration procedure that ensures the user's data and Acitve Directory account status remains intact).

Don

Ben.Toms at grey.com Ben.Toms at grey.com

[Mbentley777]

Curious to know if your migration procedure is a printed one - or a script
controlled automation procedure.

[Mbentley777]

For what it's worth, we've seen issues like this with iMac's as well - I
don't think that this is a hardware specific / OS specific issue, think
it's more to do with Homesharing and how it interacts with 10.6's feature
'Wake on Demand'.

That's my hunch anyway. In both cases (Thunderbolt and iMac) we've noticed
issues with machines that were asleep, then woken up by media access from
a remote AppleTV. In both cases, turning off HomeSharing on the AppleTV,
and then turning it back on caused the machines to display in the
Computers menu, and allowed for us to browse their contents as expected.

[donmontalvo]

Hi Matthew,

Once the data is migrated over to the new computer, the tech runs a couple simple terminal commands and they're done.
For example Local domain user "johndoe" to Active Directory user "jdoe",

sudo mv /Users/johndoe /Users/jdoe sudo chown -R jdoe:"DOMAINgroup" /Users/jdoe

I remember seeing a script for doing this in Tiger days, not sure if one exists for Snow Leopard. If so I'd love to see it, as well I'd love to know what the success/failure rate is for the script. If it's a pretty safe script with high success rate, I would even say it's worth looking into whether we can provide via custom trigger in JSS. :)

EDIT: found the URL:

http://blog.macadmincorner.com/migrate-local-user-to-domain-account/

Thanks,
Don

[RobertHammen]

Just a couple of things:

a) does anyone who has a Thunderbolt MacBook Pro come up with a list of new or updated kext's and other system components in 10J3210 that are different from a "stock" 10.6.6 system
b) I would encourage anyone who has access to a Thunderbolt MacBook Pro, has developer seed access, and has a 10.6.6 master image, to download the seed and apply it to their master, then attempt to boot the Thunderbolt MB Pro from it and see what your results are (just don't post them to the list - post them to devforums).

I don't want to violate any NDAs here, just think anyone who has expectations that this will function as it always has, needs to test this for themselves.

[bentoms]

Ok. 10.6.7 NetBoot didn't work for us.

So what we're doing till 10.6.7 is properly released (we'll then rebuild NetBoot & base os), is the following:

1. From box create our standard admin account.

2. Set macs name to asset tag.

3. Run quickadd.pkg.

4. Run: sudo jamf policy -trigger <manual trigger for policy that contains all build apps> this policy also contains another trigger to run our standard setup policy. (ad bindings, admin accounts etc).

All working fine till we need a rebuild!

I also built an applescript app that would do the above & prompt.

Regards,

Ben.