Casper Imaging 8.6 Not Naming Computer

[ernstcs]

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?

[ernstcs]

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.

[nick]

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

[Chris_Hafner]

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!

[phalcomb]

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?

[curullij]

Hi Nick,

I'm still seeing this with 8.62

[bazcurtis]

We are seeing this as well.

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

[rhysforrester]

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.

[franton]

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!

[matthewbodaly]

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.

[matthewbodaly]

errr.... doublepost. edited.

[matthewbodaly]

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.

[timmohr]

I think it's time for JAMF to come to the party on this issue, hopefully in the form of an update!

I have tried the solutions from both Olivier and nick but unfortunately I still have systems that aren't getting their computer names after imaging.

JAMF, please; do you have a timeframe of when this will be fixed?

[rhysforrester]

This is the moment it consistently happens in our Imaging workflow (/var/log/jamf.log)

Wed Nov 14 15:53:40 LAB-GPS520-XX jamf[11057]: Rebooting computer immediately...
Wed Nov 14 15:55:02 No Name jamf[255]: Checking for policies triggered by "startup"...

I'm currently `networksetup -getcomputername > $receiptfile` and then getting support staff to trigger a script that reads that and does a -setcomputername (IF) they find the name to be blank.

Would I be right in guessing that the above scripts are being used with launchd in order to run after the post imaging screen?

[nick]

Hey everyone,

We have been in touch with a few of you offline to get some more details and are very interested in getting to the bottom of this issue. We don't have any updates at this point, but we'll be sure to keep you posted as we get more details around this issue.

If you are seeing the issue, we urge you to contact your Account Manager so we can get to the bottom of it. We can also work with you to provide an acceptable workaround for your imaging workflow.

We are very interested in getting to the bottom of this and will hopefully have more info soon.

Thanks!
Nick

[drheiner]

Here is the package I made for our Company which fixes the naming issue with 10.8 using Jamf 8.62, I call it a patch. It is using this Discussion information. I compiled it into a package. You need to run this package right after the base image is layed down on the "Casper Imaging Tool"
so stick it as Priority 2, while your OS image is Priority 1. This is before the restart. Enjoy

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

Daniel

[chris_kemp]

Just chiming in here - tested imaging after upgrading to 10.8.2 Server and Casper 8.62 today, & my test machine also did not get its name, it is registering as netboot03. :-

[johnklimeck]

dhreiner,

Got your pkg. Seems to work. The name sticks after reboot. Not sure what it does. Tried to extract the .pkg, nothing seems to be there.

Might you post what files / changes are in the pkg. Thanks so much in advance.

JohnK

[tanderson]

I'm having the same issue as well. Very frustrating and hoping for a fix soon. 10.8.2 NBI, Casper Imaging 8.62, and 10.7.x configurations.

Also tried running Imaging from 10.7.x and no difference.

For now, I've created a package that runs as part of the JAMF first run that deletes preferences.plist. We have a script that runs after first run that renames the computer anyway. However, this won't work on our classroom and loaner systems that get a special use name that had been set by the JSS up until now. Now to figure out a way to handle those.

[msimpson]

Casper 8.62
OS X 10.8.2

Same issue here as well. About to image 210 computers. I'll try the package provided by driehner.

We have an additional issue (which I believe is tied into the same problem) - it resets all the network settings on reboot. But given that all these are stored in the SystemConfiguration folder it seems to be the same issue.

[franton]

Our solution where I am was to imitate Oxford university ... a bit. We have a package that's installed on the computer at image time which contains a firstrun script to do all the magic. I'll copy the relevant bit out for you all.

MacModel=$( ioreg -l | awk '/product-name/ { split($0, line, """); printf("%s
", line[4]); }' )
PrefModel=$( defaults read /Library/Preferences/SystemConfiguration/preferences.plist Model )

# Fix the incorrect model name in /Library/Preferences/SystemConfiguration/preferences.plist
# Also make sure the .plist is in the correct format

if [[ "$PrefModel" != "$MacModel" ]];
then
  /bin/echo $AdminPW | sudo -S defaults write /Library/Preferences/SystemConfiguration/preferences.plist Model $MacModel
  /bin/echo $AdminPW | sudo -S plutil -convert xml1 /Library/Preferences/SystemConfiguration/preferences.plist
fi

# Fix the incorrect network service names
# Script lovingly stolen from https://jamfnation.jamfsoftware.com/discussion.html?id=3422

# Detect new network hardware
networksetup -detectnewhardware

# List all network services and read one by one
networksetup -listallnetworkservices | tail -n +2 | while read service
do

# Remove asterisk from string for renaming disabled services
service=${service#**}

# Use filter to select next line which has the hardware port defined
filter=false

# Display network services
networksetup -listnetworkserviceorder | while read serviceorder
do
if [[ ${filter} == true ]]
then
# Grab hardware port
hardwareport=`echo ${serviceorder} | sed -e 's/(Hardware Port: //;s/, Device:.*//'`
# Check if service name if different
if [[ ${service} != ${hardwareport} ]]
then
# Rename the network service
networksetup -renamenetworkservice "${service}" "${hardwareport}"
echo -e "Renamed network service "${service}" to "${hardwareport}""
fi
fi

if [[ ${serviceorder} == *${service} ]]
then

# Got the line with the service. Set the filter to true to grab the next line which contains the hardware port
filter=true
else
filter=false
fi
done
done

# JAMF imaging should have set the machine name correctly. Let's make sure hostname is also set properly

setName=`networksetup -getcomputername`
scutil --set ComputerName ${setName}
scutil --set LocalHostName ${setName}
scutil --set HostName ${setName}

What I discovered and have since reported to JAMF is that in the /Library/Preferences/SystemConfiguration/preferences.plist file where all the network config inc. machine name is stored ... well it's all stored under a key containing the model name of the machine you build your deployment image on.

This is ok if you have all the same machine type, (iMac 7,1 for example) but not so good if you are imaging a mix of machines as I imagine you are. Mac OS basically goes as follows: 1st boot : There's a config file, but i'll interpret it as best I can. 2nd boot : There's a config file here. It doesn't contain the right info for this machine model. There's no config for this model ... i'll just write in the defaults and append it to the end of the file.

So the /Library/Preferences/SystemConfiguration/preferences.plist file balloons in size, erases the host name and resets any networking configuration. My script has been pieced together from various places but the net effect is that it does cure things.

[mscheffler]

I'm seeing something similar long after imaging is done. The computers comes off imaging just fine with the right names, but later on (months down the road) I'll realize a computer is missing from the JSS Inventory only to realize that JSS has decided to list "localhost" as the computer name. So far I've seen 3 computers get their named changed to localhost.

[nick]

Hey everyone,

Thanks for all of the details you've provided to help us reproduce this issue. The issue of a computer name being removed during the re-imaging process still appears to be an Apple defect and can be seen outside of Casper Imaging when capturing a 10.8.x image from one hardware type and restoring that image onto another hardware type.

We were able to consistently reproduce the issue by capturing a 10.8.2 image on a MacBookAir5,1 using Disk Utility and restoring it to a MacBookPro5,5 using Disk Utility. As many of you have mentioned in previous posts, OS X appears to be modifying the preferences.plist file in this scenario into a state where the computer name that was set prior to booting the target machine is removed. We've filed an Apple RADAR (12973064) and we encourage others to do so as well to add some weight to this issue.

We realize that this issue is breaking imaging workflows for some people and we have come up workarounds that can be implemented within a Casper Imaging update as well as in a NetBoot image that contains the current version of Casper Imaging.

In Casper Imaging 8.61, we added a workaround to this issue that was filed as D-003108. The fix was to add a line to the JAMF FirstRun enrollment script that set the computer name a second time after the machine rebooted. While this fixes the issue most of the time, there still are edge cases where the FirstRun enrollment script is run before OS X modifies the preferences.plist file.

We'll have another fix for D-003108 in the next release of Casper Imaging that will only run the JAMF FirstRun enrollment script after the preferences.plist file has been modified by the OS, which should resolve the edge case scenarios where we see computers losing their names. We don't have an ETA on when this fix will appear at this point, but we're very interested in helping people create workarounds for the issue.

One workaround is to remove the following file from your image:

/Library/Preferences/SystemConfiguration/preferences.plist

Note that this file is required if you'd like Casper Imaging to modify network settings (setting static IPs, etc).

A second workaround is to use one of the scripts mentioned above that renames the computer via a shell script upon reboot. If you are binding to AD or running any other items during the FirstRun process that requires the computer name to be set, you'll want to likely kick those actions off via a policy using a shell script that runs AFTER the computer name is set.

A third workaround is to compile a configuration that includes an OS X installer image of 10.8 and use that as your base image.

A fourth workaround is to create separate 10.8 images for each hardware type you'll be imaging.

There are probably a few more workarounds that we haven't thought of yet, but these are the ones we've been testing with very good success.

Thanks,
Nick

[ernstcs · Accepted solution]

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

[tkimpton]

Problem with your method is that if it tries to bind to the domain BEFORE it runs your naming fix, then your going to have to then bind it manually because it would fail.

Whilst you've just got this, I've been using my fix posted on here for a VERY long time, even before this problem arose for other reasons.

You would have saved yourself a lot of pain and stress.

[ernstcs]

I don't think you followed what I said, or I just said it poorly. FirstRun binds first, it needs to bind before the script runs or else this method would fail (and I'm sure that it will on rare occasion). I think you also use AdmitMac, which is different from us. This fix doesn't even look for the name until after the FirstRun finishes and does its reboot and then the newly installed startup item does it's work. You're method also requires my primary partition to be named different from the default, not? We won't be doing that here, and people rename volumes all the time. It's cool your method works for you, but it's not going to work for everyone. This took me very little time, and they worked the first time, no debugging (was quite proud of that actually, I didn't have a stupid typo somewhere). I would have done it a lot sooner, like back when I originally posted, but I didn't have to mass image labs until now and we weren't doing a large upgrade for office users yet. I have lots of other things to do besides Mac management. I'm just sharing in the event others wish to use this method if they have a similar setup to us.

[amalloy]

Forgive me if I reference things incorrectly but I am new in this software. I just got done updating my software to the 8.63 in hopes the work around that was just talked about would cure this corrupt plist problem I am having just like everyone else here. But I am getting the same problem again - the image pushes down, renames the machine and joins the domain. Everything looks great, then after a reboot - poof ! all the magic is gone. Like I said I am a noob to both the Casper and MAC world (a good bit of microsoft experience). Could someone help me to understand the other workarounds with scripts - this is getting very frustrating.

[amalloy]

Forgive me if I reference things incorrectly but I am new in this software. I just got done updating my software to the 8.63 in hopes the work around that was just talked about would cure this corrupt plist problem I am having just like everyone else here. But I am getting the same problem again - the image pushes down, renames the machine and joins the domain. Everything looks great, then after a reboot - poof ! all the magic is gone. Like I said I am a noob to both the Casper and MAC world (a good bit of microsoft experience). Could someone help me to understand the other workarounds with scripts - this is getting very frustrating.

[amalloy]

Forgive me if I reference things incorrectly but I am new in this software. I just got done updating my software to the 8.63 in hopes the work around that was just talked about would cure this corrupt plist problem I am having just like everyone else here. But I am getting the same problem again - the image pushes down, renames the machine and joins the domain. Everything looks great, then after a reboot - poof ! all the magic is gone. Like I said I am a noob to both the Casper and MAC world (a good bit of microsoft experience). Could someone help me to understand the other workarounds with scripts - this is getting very frustrating.

[Paul_Price1]

Thank you Craig. Your script that is marked "Answer" got me out of a jam today. Your post was clear and usable by a NOOB like me.

Sincerely,
Paul

[amalloy]

Craig, I was trying to implement your solution and I was still having problems. I think it's how or where I am trying to run the script. Could you help me understand the process of setting up the policy that installs the Startup script. I understand the concept of what is happening, but I don't think I know how I can get the rename to happen when I want it to.

AJ

[CasperSally]

Another newb who could use some help from someone on Craig's solution. The part I'm missing is making the startup item self deleting? Thanks!

[stevewood]

If you simply have a script that you want to delete itself, just adding this line at the end will do that:

# Make script self-destruct

srm $0

If it is a LaunchDaemon that you are trying to get rid of, you can do what JAMF does with their first run stuff:

## Delete this script and the corresponding launchd item
/bin/rm -rf '/Library/Application Support/JAMF/FirstRun/PostInstall/'
/bin/rm /Library/LaunchDaemons/com.jamfsoftware.firstrun.postinstall.plist

## Remove the corresponding launchd item
/bin/launchctl remove com.jamfsoftware.firstrun.postinstall

Make sense?

[amalloy]

I appreciate the help Steve, the part I was having problems with was the

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

I created a policy that will run that script, but I guess its just running it as part of first run? I get the feeling that I'm missing something obvious here, but not sure what it is.

[stevewood]

Craig can clear this up if I'm wrong, but I would venture to guess that he has a policy in the JSS that he calls with a custom trigger. That policy then installs a script somewhere on the machine and places a LaunchDaemon on the machine to run at next login. The script and LaunchDaemon would clean themselves up after running.

Imagine a policy with a custom trigger of "renamecomputers". Your First Run script would then call that policy with something like this:

jamf policy -trigger renamecomputers

The policy itself would simply have a package that installed the actual renaming script somewhere on the machine, maybe in /private/var/<companyname>/scripts, and it would also install a LaunchDaemon named com.company.renamecomputers.plist in /Library/LaunchDaemons. That launchd item would look like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.company.renamecomputers</string>
  <key>ProgramArguments</key>
  <array>
    <string>/private/var/<companyname>/scripts/renamecomputers.sh</string>
  </array>
  <key>RunAtLoad</key>
  <true/>
</dict>
</plist>

The renamecomputers.sh script would do the magic that renamed your computers, and then at the very end of the script, you'd have these lines:

/bin/rm -rf /private/var/<companyname>/scripts/renamecomputers.sh
/bin/rm /LIbrary/LaunchDaemons/com.company.renamecomputers
/bin/launchctl remove com.company.renamecomputers

Is that what you are looking for? And does it make sense?

[ernstcs]

Steve's spot on. Sorry I couldn't reply sooner.

So my process is dependent upon using native Active Directory binding as part of imaging. I can't test this with ADMitMac or the others.

As part of Casper Imaging I have a script that runs At Reboot that calls a policy I've created.

#!/bin/sh

## This will install the FixComputerName package
/usr/sbin/jamf policy -trigger FixComputerName

The policy trigger of Other with a Manual Trigger name of FixComputerName

That policy installs a package that's a StartupItem (I should switch to launchdaemons). Once the FirstRun process finishes it should reboot the computer which will then have the StartupItem run. The StartupItem deletes itself when it's done.

You can download my StartupItem here (link will expire Feb 14th), but you'll have to edit the script inside for your needs as mentioned in my answer. TEST TEST TEST. StartupItems are really particular about their structure, file names and permissions.

https://staff.uwec.edu/Handlers/AnonymousDownload.ashx?file=469ada19

[CasperSally]

Thanks Craig and Steve, appreciate it.

[Lotusshaney]

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

[CasperSally]

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

[tuinte]

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

[MikeF]

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