I had the exact same problem imaging 10.8 Macbook Airs. Until I noticed that If I restored an Image built on a different model of Mac I did not get the problem.

In /Library/Preferences/SystemConfiguration/Preferences.plist there is the following key :-

<key>Model</key>
<string>MacBookAir4,2</string>

If I removed the key from the plist and took an image it would get set clients 3 names just fine from Casper Imaging.

Dan

It looks like this issue is addressed in 8.64 - if anyone upgrades and it fixes the mtn lion naming issue, if they could report back that'd be great.

Fixed in v8.64:?
[D-003108] Fixed an issue that prevented Casper Imaging from naming computers when deploying an OS X v10.8 configuration.
??

CasperSally:

I am still seeing the issue - computer is named localhost. This is everything updated to 8.64, imaging via netboot to 10.8 machines. Colour me sad.

Michael

I did one last night and it worked properly for me. Now I will have to test again

bump. any other feedback on Mtn Lion naming issue with 8.64? It's something it's not easily tested in my test environment, unfortunately. hoping it's fixed. will report back if/when we update production.

I ended up upgrading today and so far it appears 8.64 corrects the issue for us. Mountain Lion machines are correctly keeping their name post image (even on models different than the image build machine).

I had the exact same problem imaging 10.8 Macbook Airs. Until I noticed that If I restored an Image built on a different model of Mac I did not get the problem.

In /Library/Preferences/SystemConfiguration/Preferences.plist there is the following key :-

<key>Model</key>
<string>MacBookAir4,2</string>

If I removed the key from the plist and took an image it would get set clients 3 names just fine from Casper Imaging.

Dan

I tend to remove SystemConfiguration from my base OS images anyway, so I don't get the network configs from my imaging mule. This means I have to run a script during imaging to set my proxies, but that's better, actually.

Let's say you have an iMac and capture the base OS from that - well, when you slap that on an Air, you're going to have a few too many network interfaces (and unpredictable identifiers for the "actual" interfaces - is "en0" WiFi like it should be, or is it the Ethernet - which doesn't actually exist?). If you go the other way (capture the OS from an Air, apply it to an iMac) whatever configurations you made to network interfaces (proxy, etc) would only survive for the interfaces the two devices have in common (so the Ethernet device on your iMac won't be "configured").

Also, SystemConfiguration is where your device-specific details live (I'm speaking very generally, here) so it's a bit cleaner to just hose that folder and let it be re-populated when the OS runs on the new hardware.

I see now that this has been discussed at some length; I can say, however, that I remove the folder and don't have naming problems (the name I set in Imaging is set on the machine).

@JPDyson - thanks for the response. I will look at that prefrences.plist next time.

I do remove portions of SystemConfiguration already (see https://jamfnation.jamfsoftware.com/discussion.html?id=4521) - but I don't want to hose the whole folder because I want certain settings (device pref order I think is one) to stick around.

Trashing the preferences.plist file in Library/Preferences/SystemConfiguration before using Compser to capture my Base image fixed this for me. I had my base image computer in target disk mode via Thundebolt.

Very nice to have my computer names stick on the machine and in inventory.

Still seeing this issue in netboot of 10.8.3 using 8.64 Casper Imaging. It grabs the name and then after a reboot it loses it and my logs state that the network changed and configd changes the name to loaclhost.
Not sure whats happening but seems this issue is not resolved.
Gabe Shackney
Princeton Public Schools

@gshackney - see my post up above. That fixed it for me. You will have to redo your base image though with that preference file trashed before capturing it.

Thanks trying that now...

This is the solve for me as well! Thanks thanzig, after reviewing this thread it looks like I posted this same hint way at the top a long time ago...guess I just forgot my own advise.

Gabe Shackney
Princeton Public Schools

I have been following this post for a while now and the only fix that works for me atm is the script which uses the AD Bound name to re-name the machine. I created a smart group for machines called "localhost" then a ongoing script that will run and re-name the machine.

I only get this problem on desktop Macs, we just received the latest iMac, so I setup the iMac out of the box and created a brand new base image. I have even removed the following file (/Library/Preferences/SystemConfiguration/preferences.plist) just to be sure. After the machine is imaged it still re-names the machine to localhost.

@ gshackey - you did have me confused because I took your original advice about removing the preference!

@ pnbahry - that is a tough one to figure out. when are you removing the preference.plist file? I removed mine when I had it slaved to my Composer computer. If you remove it and the reboot it, it will generate the preference file again. I created my base image using a 10.8.2 netinstall on an older i5 Macbook Pro. Updated it, tweaked some settings and then target disk moded it while trashing the preference file and sleepimage file before using Composer. How are you creating your base image?

Your solution does seem like a good one though.

JAMF claims this is fixed in 8.64. In brief testing, it looks like this is no longer an issue.

@cbrewer This is still an issue since if you read the comments we are all mostly using 8.64. But this looks limited to instances where you use the base image from the same model mac; IE late 2012 iMacs being imaged from a base created from a late 2012 iMac. At least that is how I am replicating it. It does get resolved for me removing the /Library/Preferences/SystemConfiguration/preferences.plist right before you are about to capture the base image (as mentioned above it will recreate this preference when you reboot the machine).

Gabe Shackney
Princeton Public Schools

I just wanted to share that this may no longer be a problem for some. I was previously removing preferences.plist as part of my 10.8 work flow. I'm no longer removing it and have yet to see an issue with the computer name being blank. I've tested using the same model hardware as well as different hardware.

Scroll up 100 pages to my script, if you ignore it then its your peril. I cant take 100 percent credit and after 12 beers (yes us british like our beers) i cant remember where i got the idea from let alone this post is taking half an hour to type lol

We still need to remove the preferences.plist with a FirstRun post build script, as the naming issue is occurring on similar hardware that the base image was created with.

Versions used:
Mac Mini Mid 2011
OS X 10.8.3
Composer 8.63
Casper Imaging 8.64

Our issue may have something to do with an older version of Composer being used to create the base os. I will try the 8.7 tools and post back results.

Thank you everyone for this thread. It saved me a lot of time today. I made our master image on a MacBook Air 13" and hit this bug when I put it on our MBA 11". By changing "MacBookAir5,2" to "MacBookAir5,1", in preferences.plist, I was able to save myself a lot of time.

@matthewbodaly : If you use ```
jamf getComputerName | awk -F'<|>' '{print $3}'
``` you can have names of variable length and impress your Physics teachers with your knowledge of bra-ket notation. I am shamelessly stealing your idea of using local text files to check that the name of the machine has not changed.

So being the 98th commenter and this is still going on...what's the solution? Delete this file in my base /Library/Preferences/SystemConfiguration/preferences.plist? Wait for JAMF to come up with a solution? I have a pile of student computers I need to image and really don't want to name them twice.

I think you also use AdmitMac

This has nothing to do with it. If you read my post properly I said this is what i do and doesn't run as a first run script but with a launch daemon

Please be careful with your put me downs. Like I said it works for me because of my hard drive naming convention. Common sense should say to you you need to adapt it for you.

Sorry but in getting a bit narky with the amount of people on here that want things handed to them on a plate without carrying out and engineering.

Where's my wet wipes!

1. READ Daniels post.




2. Download his pkg

http://home.comcast.net/~Nw_systems/Ivy_ACOE_OSX10.8_Patch.pkg

1. Put it in pacifist and analyse it to make sure it's not dodgy (no offence Daniel its best practise to not blindly install stuff)




2. If all looks OK then follow his instructions!




3. Stop moaning and get stuff done.

No offence intended to the many engineers of whom have posted their own solutions.... Respect.