I just tried imaging a system with 10.8.1 with Casper 8.6, a system that was consistently not naming after imaging, and now it is. =D

ernstcs

I tried imaging a system with 10.8.1 and it still isn't naming for me. The name is blank and the AD bind is set to "no name"

Nice.

Did they ever respond to your question?

Not sure what to say there. Pretty sure JAMF was going to test again with a system(s) they've been unable to name. I was trying to figure out if it was somehow hardware specific, but that's been difficult. I guess we keep plugging away and see what else comes up.

I patched my existing 10.8 build created on a 15" MBP Retina running the softwareupdate -i -a command. I do standard Composer OS images. Although, I didn't patch on the MBP, I made the updated image on the iMac I've been having issues on. Perhaps I'll grab another of those iMacs tomorrow.

These issues are the worst. Some people see it and others don't. Someone sees Self Service crash. Others don't. Lots of variables on how you made your images, etc.

After running more tests with the following
jss 8.6
netboot 10.8
Casper Imaging 8.6
OS being imaged 10.8.1
one computer had a name already in the JSS inventory and one did not. Neither were named. The one that already had the name, had it removed in JSS' inventory.

no name... right now I'm about to upgrade my netboot image to 10.8.1 and cross my fingers.

Well I thought it was fixed as well after upgrading to 10.8.1 but here's what I'm finding out, at least in my case.

If I create the image on a Retina, the naming works fine on the Retina but the naming doesn't work on a MacBook Pro.

If I create the image on the MacBook Pro, the naming works fine on the MBP but not the Retina!

UGH,
Anyone else want to double check this?

This is my workaround

All my machines have the HDD Volume to match the computername and start with LDN

#!/bin/bash



### INTRO ###

# 10.8 bug where machine name doesn't get applied. This script gets the volume name starting with LDN and makes sure it is the computername



### VARIABLES ###



# Make sure the config file exists

touch /Library/Management/Scripts/computername.conf



# Write to the config file

volume=`ls /Volumes/ | grep LDN  > /Library/Management/Scripts/computername.conf `



### DO NOT MODIFY BELOW ###



# Compare what is in the computername.conf to the current computername and if they do not match it will change it



current_computername=` /usr/sbin/networksetup -getcomputername`



set_name=` /bin/cat /Library/Management/Scripts/computername.conf`



# Now to compare both of the strings

if [[ $current_computername = $set_name ]]



then echo "All looks good, computer name checks good"



else /usr/sbin/networksetup -setcomputername $set_name

scutil --set ComputerName $set_name

scutil --set HostName $set_name

scutil --set LocalHostName $set_name

fi



exit 0

I then package up and deploy the script in the build along with a launch daemon to run it.

@FastGM3

The image I tested earlier were based on 2011 MacBoo Pro's being imaged back onto 2011 MacBook Pro's Still no name. right now I've updated my NBI to run 10.8.1 itself and I'm crossing my fingers.

how are you guys creating your images? Composer captures, modular Casper Imaging images based on the InstallESD.dmg file, instaDMG, or ?

The fix for this problem is beyond me and probably my pay grade and competence.

Based on my testing today here are my results:
Casper Suite 8.6
Imaging from OS 10.8 (regular OS images that logs in as root, not netboot or netinstall)
Applied OS images Mountain Lion 10.8 or 10.8.1 (10.8.2 beta not tested)
Using Composer or Disk Utility to create the OS DMGs

In my opinion this issue is hardware bound, meaning that computer naming will work fine on the same model hardware the Composer or Disk Utility OS image is created on. I found this to be true when working between two iMacs of the same model.

In testing I would take an existing OS DMG that would have machine naming break after Casper Imaging, on that same machine take that same OS DMG and apply it via Disk Utility, boot to that partition and not even login (but I did have to boot to it at least once, if not it still broke, the OS is doing some of its own magic here apparently when it first boots), reboot to my imaging partition, simply run that partition through Composer to generate a new OS image, and using that with Casper Imaging now makes computer naming work for that same hardware, and then not others including the one the original image came from.

So the simple act of running that partition through Composer to build an OS image on the particular hardware model you want to work, will. SO in theory you could have a separate OS image per model for the time being, but the renaming methods folks have put together are your most sensible option if you tested them to work.

In my opinion this is up to JAMF and Apple to sort out unless you have lots of free time and the know how I lack to troubleshoot it further. Even when I apply the OS image from one model to the other with just Disk Utility there is no name, but there is with the same model, which to me suggests it's not even something JAMF has done with Composer or Casper Imaging.

Testing with beta on Monday as I'm sure it's still an issue there, and will submit a bug report.

I also had this issue, and I lost my hair during 2 weeks to fix it.

Let me share my experience :

- We use a modular image approach. We boot on a NetBoot image or use a USB disk to deploy the image and other packages to internal Mac HDD.
- We build a Composer image on a MacBook Air, and try to deploy it on MacBook Air, MacBook Pro and other Mac hardwares.
- CasperImaging had some problems to set the computer name : it was also blank and obviously, domain join failed or name was, as many said, localhost.

In fact, I don't think Casper is the problem as it relies on underlying stuff (I suppose something like scutil, but scutil cannot be use, AFAIK, to set computer name on a partition which were you are not currently booted on.

The mystery remains in /Library/Preferences/SystemConfiguration/preferences.plist as one said.

Imagine there is an existing "Sets" entry in the plist (the "Sets" seems to be bound to the hardware type), and you change the hardware (happens in case you use a modular image, and target machine is not the same type as original machine). Before you reboot, the computer name resides in System:System:ComputerName and System:Network:HostNames:LocalHostNames key.

After you reboot, OSX moves the whole tree subset to "name of the previous hardware":System:System:ComputerName and "name of the previous hardware":System:Network:HostNames:LocalHostNames key.

In my case when I boot the MacBookPro, it moved the tree to MacBookAir4,2:System:System:ComputerName and unfortunately, leaves the proper System:System:ComputerName non-existent, resulting in empty computer name.

In some cases (sorry don't remember when), the OSX image I put on the internal disk gets the computer name of the USB disk under the one I booted previously and which is still connected : OSX is so smart that it gets the computer name from /Volumes/myusbdisk/Library/Preferences/SystemConfiguration/com.apple.smb.server.plist located on my USB disk, and re-use it to populate the /Library/Preferences/SystemConfiguration/preferences.plist.

So here what I did :

Create a PKG file executed immediately after you perform your block copy and before computer name is set by Casper. This is because scripts will be executed "after the fact" and I am too lazy to spend my time fixing stuff after it is too corrupted or after first reboot.

In this PKG, only create a postinstall script with commands :

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"

I thought at the beginning to delete the whole preferences.plist file from my main DMG file, or delete it with the PKG and method above, but it does not work well in some cases (don't remember why again, maybe in case there are USB disks still connected to the computer with com.apple.smb.server.plist file).

For me, the behavior is clearly not the same as in 10.7, so Apple must have changed something.

I don't know if anyone else is experiencing the following additional naming issue. I have several units (Imaged as mentioned above) to 10.8 who are not taking the newly assigned name from the JSS inventory. The computer name recorded in the JSS record actually get's wiped and replaced the localhost(). Any thoughts there? I'm a week from D-Day and hope that Apple releases 10.8.2... I'm also hoping that this fixes the issue.

EDIT! Never mind... there was some cross imaging. Nothing in the JSS is losing it's name. Sorry if I got anyone going!

That would be normal after imaging. localhost is what the OS is naming the system when there is no name provided or set properly. After imaging runs and it does its initial recon it would normally update the computer name in the JSS to the same, which is localhost.

There is currently no setting in the JSS (shakes fist at JAMF) to always retain the computer name that's in the JSS and force it onto the clients to FIX them when they recon. Some of us get around that by other means of course.

Quite correct. However, we simply name them after imaging/recon and set the computer name along with the daily inventory. I goofed and through some hectic testing while moving offices thought that names were changing back to localhost post recon/imaging. I was however, quite wrong.

Unfortunately it doesn't look like Apples recognizing the problem quite yet. I'm prepping our LDAP to handle our naming this time around. Not happy about it, but it works.

Any update on this issue?

I have not heard anything new at this point, and have not tried the latest Beta build to see if something magically was put in that.

Hey everyone,

We have addressed this issue in our next release, which is due out very soon. A workaround is to set the computer name via a script that runs at reboot. The next version of Casper Imaging will actually set the computer name as one of the first actions that takes place after the computer boots for the first time.

Here is a sample of a script that can be used as a workaround for the time being:

#!/bin/sh

LOGPATH="/var/log/jamf.log"

NAME=`grep "Set Computer Name to" $LOGPATH | tail -1 | sed -e 's/.*Name to //'`

/usr/sbin/jamf setComputerName -target / -name "$NAME"

Thanks,

Nick

Fantastic, thanks! From a Q&A Standpoint this adds the bonjour name (meaning that it interjects .local at the end of the name) but it certainly works! Thank you very much!

Nick, I've found that this hasn't been addressed as mentioned in the 8.61 release notes. Once the computer is imaged and I check the compuername and it's there. After the first reboot it disappears. I've notified support but do you have any clue as to why that might be happening?

Hi Nick,

I'm still seeing this with 8.62

We are seeing this as well.

We can't even type a machine name in the machine name field. We emailed support today.

NetBoot 10.8.2 auto login as root with Imaging 8.62 / Installing 10.8.x built with Composer. Another NO NAME here.

It was occurring early in my post-imaging process, but after updating the netboot and image to 10.8.2 it's now occurring consistently after the deletion of the adobeinstall account.

Love the script up above Nick, definitely going to incorporate this - thank you! But a script? Isn't naming a big enough deal to have a patch out already incorporating said script. Fair enough it's Apple dragging the chain, and please excuse me if this sounds frustrated, but active directory binding, bonjour networking, deployment, these are all borked if that name doesn't set right!

Honestly, can't thank you enough for that wee bit of code.

Something we've discovered is that DNS can play havoc with machine naming. Our situation is that the mac gets it's name from the inventory via pre-stage imaging, first boot after imaging is ok, second boot loses it's name every time.

What we've discovered is that our authenticated DNS isn't allowing the macs to set their name at first boot, so at 2nd boot the mdnsresponder fires off a DNS request and is overwriting the macs hostname with a blank record.

The only fix i've found involves having both microsoft DNS and DHCP servers, a dedicated DNS authentication account and setting the DHCP server to do the following:

1) Use the authentication account as credentials for updating DNS.
2) Set "Dynamically update DNS A and PTR records only if requested by the DHCP clients" option
3) Set "Dynamically update DNS A and PTR records for DHCP clients that do not request for updates (for example, clients that are running Windows NT 4.0)" option

This seems to have fixed our issues with this. I am now awaiting our systems team to roll this out!

This happens on our install as well. I've been able to reproduce this on computers that are not bound to AD / OD.
- New computer (base install from Apple)
- Rename computer to our company naming scheme
- Add Casper policies
- Restart
- Computer name changes
- Manually rename
- Restart computer
- Computer name changes

Ive been able to see this when the computer is unplugged from the network as well.

errr.... doublepost. edited.

Ok. I narrowed this down and have resolved this on my side.
Issue: The latest version of Casper and the latest OSX have something in them as a conflict. Whenever the computer changes network interfaces, the computer name changes to .localhost. Here is how I fixed it.

1. I wrote a small script that pulled the Casper computer name and wrote it into every spot in OSX that wanted a name and set the hostname of the computer. This also wrote a small file with the computer name in it into a flat file so I could refer to it later if I needed.

#!/bin/bash

# this ninja takes the name that the computer has in JAMF and then renames 

# all computer variables to that name AND adds a flat text file at

# /Library/Application Support/assettag

# Make a folder to store resource files. Commenting this out since this line isn't needed

# when the script is deployed via Casper. Uncomment to enable. Also change the cut numbers based on the length

# of computer names

mkdir /Library/Application Support/caspersupport

# Get for the name of the computer from Casper and write it to a file

jamf -getComputerName | cut -c 16-24 > /Library/Application Support/caspersupport/assettag

# Set entry as a variable

BELUS=$(more /Library/Application Support/caspersupport/assettag)

# Backup the file that will be changed

cp /etc/hostconfig /Library/Application Support/caspersupport/hostconfig.bak

# Change the HostName to the variable

scutil --set HostName $BELUS

# Change the ComputerName to the variable

scutil --set ComputerName $BELUS

# Write the variable to the end of /etc/hostconfig. This uses the FQDN. If you have a FQDN... you should change this.

echo HOSTNAME=$BELUS.apptio.lan >> /etc/hostconfig

# change the Bonjour name

systemsetup -setlocalsubnetname $BELUS

The script is also here: https://github.com/matthewbodaly/rawrscripts/blob/master/computernameninja.sh
2. Instead of binding to just domaincontroller.lan, I bound the computer to a preferred domain controller. Instead of just joining the domain, I opened the directory utility and here is what the advanced settings looked like. I filled these out BEFORE binding. Once I had it tested, I created a new binding policy on Casper and did an unbind rebind on the computers.

1. Set the delay to show loginwindow on the computer at 45 seconds. I dont think this is as important as the other two but this gave the ethernet interface more time to authenticate on our network. Since we have primarily network users, this made sense for our environment. More information on that was found here : https://discussions.apple.com/thread/4286854?start=0&tstart=0

Looking back on this, I'm likely going to change the login window delay to a bit longer on our network, but I deployed this in stages and this has completely resolved the issue to this point.