Casper Imaging 8.6 Not Naming Computer

ernstcs
Contributor III

Casper Version 8.6
Mountain Lion

Although I have specified the computer name in the field for Casper Imaging and updated the information on the JSS with the checkmark as well, after imaging a system I notice that the computer has no name, all I get is localhost. Anyone else seen this issue?

1 ACCEPTED SOLUTION

ernstcs
Contributor III

As I understand it, there may be hope in the next version of the Casper Suite to put this issue to rest...for now. In the mean time, although you all have some wonderful ways of doing this, I went an even more different route since I bind to AD and that part of the FirstRun works every time since the bind script in FirstRun uses the name in the script. =D

It's probably a terrible way to do it, but I read the computer name out of the AD settings at whatever point works and then pass that through to scutil. I found it more reliable to have a simple script part of first run that calls a custom triggered policy. The policy it calls installs a self-deleting StartupItem with the script below. After FirstRun finishes and reboots, the StartupItem runs and does the rest and then cleans itself up. You wouldn't need to output it to a file like I do, that I use for later reboots where another StartupItem renames the computers back to what they were when they were imaged to maintain the same name, you know the stupid (1) and (2) after the names, etc. I run another enroll command to make sure it does, that's been spotty as hell, too.

TEST TEST TEST, and if you have any questions, let me know. Thanks for all the responses folks!

YOU MUST CHANGE your plist file name, since it won't be UWEC like mine. Also, if you have a preference on computer name case, you'll have to work around that, too.

#!/bin/sh

## Delete an existing computername.conf file if it already exists
if [ -f /private/var/computername.conf ]; then

    /bin/rm /private/var/computername.conf
fi

## Create new computername.conf file using AD binding information, and then set the computer name
if [ -f /Library/Preferences/OpenDirectory/Configurations/Active Directory/UWEC.plist ]; then

    defaults read /Library/Preferences/OpenDirectory/Configurations/Active Directory/UWEC.plist trustaccount | sed '$s/.$//' > /private/var/computername.conf

    set_name=`/bin/cat /private/var/computername.conf`

    /usr/sbin/scutil --set ComputerName $set_name

    /usr/sbin/scutil --set LocalHostName $set_name

   jamf enroll
fi

View solution in original post

119 REPLIES 119

CasperSally
Valued Contributor II

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.

CasperSally
Valued Contributor II

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

JPDyson
Valued Contributor
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.

JPDyson
Valued Contributor

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

CasperSally
Valued Contributor II

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

thanzig
New Contributor II

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.

GabeShack
Valued Contributor III

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

Gabe Shackney
Princeton Public Schools

thanzig
New Contributor II

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

GabeShack
Valued Contributor III

Thanks trying that now...

Gabe Shackney
Princeton Public Schools

GabeShack
Valued Contributor III

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

Gabe Shackney
Princeton Public Schools

pnbahry
New Contributor III

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.

thanzig
New Contributor II

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

cbrewer
Valued Contributor II

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

GabeShack
Valued Contributor III

@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

Gabe Shackney
Princeton Public Schools

cbrewer
Valued Contributor II

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.

tkimpton
Valued Contributor II

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

benyoung
New Contributor

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.

rcuza
New Contributor

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.

cohawkeye
New Contributor

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.

tkimpton
Valued Contributor II
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.

tkimpton
Valued Contributor II

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.

johnklimeck
Contributor II

cohawkeye,

Thought I'd chime in. Man, this is still going on, have been off the JN boards, thought it was fixed, but that could be in version 9.

Echo tkimpton. It works, not sure how or why, but it does. I tried to do a snapshot to see what is being installed, but to no avail. Put the patch pkg in your Casper Imaging configuration and wa la, the name will stick. It worked beautifully for me in my last JAMF environment and nothing was making the name stick, except this.

In fact the blank name issue came back because I didn't have the patch in my config, once i re added the patch, name sticks.

John K

tkimpton
Valued Contributor II

Good to know it works John and thats all that matters right :)

CasperSally
Valued Contributor II

John - if you don't want to download/use Pacificst, if you download the pkg and drag it into composer, in the left menu bar and select create source, it lets you see the contents of the pkg. You'll see it's basically just doing following (from scripts folder)

defaults delete "$2/Library/Preferences/SystemConfiguration/preferences" NetworkServices
defaults delete "$2/Library/Preferences/SystemConfiguration/preferences" CurrentSet
defaults delete "$2/Library/Preferences/SystemConfiguration/preferences" Sets
defaults delete "$2/Library/Preferences/SystemConfiguration/preferences" Model
rm "$2/Library/Preferences/SystemConfiguration/com.apple.smb.server.plist"

benyoung
New Contributor

We no longer need to remove the preferences.plist with a FirstRun post build script. The naming issue has resolved itself when using the latest Casper Suite Tools.

Versions used:
Mac Mini Mid 2011
OS X 10.8.4
Composer 8.7
Casper Imaging 8.7

Process: Updated our base OS from 10.8.3 to 10.8.4
Captured the image with Composer 8.7 (Using defaults options)
Updated NetBoot to OS to 10.8.4 with Casper Imaging 8.7

We have tested on two different models of Mac only at this stage, but will continue to test before release into production. I would be good to get others to see this has worked for them?

tkimpton
Valued Contributor II

@CasperSally

No No No! Any pkgs that have preflight and post flight script will run on YOUR machine if you drag them in to Composer!

If you do this you could screw up hour machine!

This is why we use Pacifist!

tkimpton
Valued Contributor II

@CasperSally

No No No! Any pkgs that have preflight and post flight script will run on YOUR machine if you drag them in to Composer!

https://jamfnation.jamfsoftware.com/featureRequest.html?id=1224

If you do this you could screw up your machine!

This is why we use Pacifist!

CasperSally
Valued Contributor II

Interesting - had no idea. Thanks for sharing that, Tim.

dsepton
New Contributor

We're seeing this issue losing host name after first run reboot with OS X 10.8.3+ and Casper 8.64. We've had success applying the @drheiner package (http://home.comcast.net/~Nw_systems/Ivy_ACOE_OSX10.8_Patch.pkg) in the Casper Imaging target mode process immediately after the OS DMG (PKG set at priority 2). We'll keep testing but looks good for now.

seabash
Contributor

As dsepton said, we'll keep testing for continued success w/ drheiner's pkg. A couple notes, though...

Daniel's pkg removes the following 4 entries from /Library/Preference/SystemConfiguration/preferences.plist
- NetworkServices
- CurrentSet
- Sets
- Model
It also removes the entire /Library/Preferences/SystemConfiguration/com.apple.smb.server.plist file

We're using JAMF's method for "Creating a Minimal Base OS Image", https://jamfnation.jamfsoftware.com/article.html?id=313
This method employs Composer.app, which excludes /Library/Preferences/SystemConfiguration/preferences.plist by default (on v8.64 at least).

This begs the question:
Is /Library/Preferences/SystemConfiguration/com.apple.smb.server.plist the lone culprit?

That plist contains items NetBIOSName, LocalKerberosRealm, WINS info among others.

I'll try a separate test where I exclude that .plist from a fresh OS X 10.8.4 (12E55) minimal base image.

Other notes: Casper Suite 8.64; OS X 10.8.4 (12E55).
Used a MacBookPro 15" Retina (Mid-2012) for minimal base OS image, so need to rev it when we get our newer gear. We've seen this issue on earlier Macs—from Mac Minis, iMacs, MacBook Airs, etc.

jbmiller
New Contributor III

I am in the process of updating my netboot set with the newest version of Casper imaging and have already updated my server to 8.71. I will report back results concerning the combination of 8.71 and 10.8.4. Has anyone already tested 8.71 to see if the naming problem is fixed?

chris_kemp
Contributor III

Well, I found this discussion again because my test machine is having its name nuked. >:(

10.8.4 NetBoot, 10.8.4 image push, Casper 8.71, and it's still an issue. Checked the preferences.plist, and sure enough the machine identifier is different from the machine I'm imaging.

Going to try the patch...

chris_kemp
Contributor III

Patch worked. That's good news...sure wish this would be actually fixed, though.

RobertHammen
Valued Contributor II

Just ran into this at a client today, trying the patch as part of the imaging workflow.

Chris_Hafner
Valued Contributor II

I've found that adding a quick add package to any configuration works wonders. FYI, there are lots of threads using that as an answer and it appears good for normal configs compiled configs and prestages in my experience.

drheiner
New Contributor III

Not to beat a dead horse here, Just a question to the guys that have upgrade to 9.0 (or 9.12 as of 10/18/2013) is this issue fixed? I am gearing up our company, to upgrade to 9.0 coming up. I have also been looking at OS X 10.9 I can confirm my package still works on 10.9 (From our Casper Environment 8.72.... please test on yours ) I hoping though I won't have to use this anymore. Thoughts ?

makander
Contributor

I'd also be interested in knowing if anyone has experienced this when imaging Mavericks (10.9.X) with Casper 8.74?

clifhirtle
Contributor II

@makander I definitely do see it if I do not have @drheiner 's package that selectively removes /SystemConfiguration items.

makander
Contributor

@clifhirtle Alright, that's good to know! Thank you!

chris_miller
Contributor

Running JSS 9.63 deploying OS X 10.10.2 on mid 2013 MBAirs via target mode imaging. Was having the same issues listed above.

I simply added a quickadd package to my imaging set to run at priority 2 right after the OS block copy and the issue was resolved. Am now trying this method with different hardware.

If I have Casper Imaging create a user account, then it fails again, but the user account is created. If I install a user account with a package from a source like CreateUsrPkg it fails.