Computer Name is not populating when imaging

I am having the exact same problem and the good folks at JAMF are working on
it. So far we haven't been able to figure out why it is happening.

I have tried pushing just the image, without any extra apps or scripts, and
I've tried it with the scripts and apps. Both ways yield the same result.

To get around this, I've added to my post image script a piece that pulls
the serial number of the machine and renames the machine to the serial
number. Not optimal, but it at least makes it easy to ID in ARD after
imaging is done, and then I can go in and manually change it:

# rename computer to the serial number

NewName=system_profiler | grep "Serial Number" | awk '{print $3}'
touch /$NewName
#NewName='system_profiler SPHardwareDataType | grep Serial | awk '{print
$3}''
scutil --set ComputerName $NewName
scutil --set LocalHostName $NewName
scutil --set HostName $NewName

Steve

If there is no record of that machine in the JSS it won't pull a name down. I haven't really used instaDMG so I can't give you a full reason why it is doing that. I just use Composer to make an OS image after I configure it.

You can try adding a line to your scripts as preflight to name the computer, assuming there is already a name on these boxes you are imaging?

You can try adding a simple variable to your script

compname=scutil --get ComputerName

then just call the $compname in your script to set it like this

scutil --set ComputerName $compname

I would double check my syntax there.

I'm with Tom, I've never used InstaDMG, I've always used Composer. Any compelling reasons you'd like to share as to why you prefer one over the other? I'd be interested to know.

Craig E

Full disclosure: I'm an InstaDMG n00b but I love the concept. More
On 11/11/08 4:47 PM, "Ernst, Craig S." <ERNSTCS at uwec.edu> wrote:
information about InstaDMG can be found at
<http://www.afp548.com/article.php?story=ImageCreationRevolution&query=insta
dmg>.

With Composer you have to install your Mac OS system, update it, clear
recent items lists, clear recent folders lists and rotate log files. Then
you have to boot to another disk and create a .dmg file from the first disk.
You'll image your Macs with that .dmg file.

InstaDMG allows you to create that same fully patched Mac OS X .dmg file
without having to actually image a master hard disk or boot to another disk.
The concept is similar to Windows slipstreaming.

Here's the setup.

1. I create a .dmg master of my Mac OS X 10.5.0 retail DVD and place it into
   the InstaDMG folder structure on my computer.

2. I download and place the 10.5.5 combo update and other miscellaneous
   updates like Airport, Java, ARD, etc., into the InstaDMG folder structure.

3. I run InstaDMG and about 2-1/2 hours later I have a fully patched and
   virgin Mac OS X 10.5.5 .dmg file ready to deploy with Casper.

This image has never been logged into. It still doesn't have a user yet and
will go through the Apple Setup Assistant (movie and all) once it has been
imaged onto a real hard drive.

I can take my original InstaDMG folder structure and add a simple text file
to exclude the extra printer drivers, translations and fonts. After I run it
again I now have my smaller Mac OS system for my Restore partition. It's
fully patched and still virgin.

If I need to update my OS images, I simply download the update from Apple,
add it to my original InstaDMG folder structure and run InstaDMG again.

This is where I stop because I prefer to use Casper to image and manage my
Macs. However, you could also add something like the Microsoft Office 2008
installer .pkg file and all its subsequent .pkg updaters to the InstaDMG
folder structure too. You'll have a fully patched virgin Mac OS with a fully
patched Office 2008 installation.

Here's why I like it.

It leaves 0% cruft behind. No remembered servers, no recent items list, no
byhost files, no user preferences, no un-rotated log files. It's perfectly
clean. And the time to create an InstaDMG Mac OS X .dmg file is comparable
to or faster than installing onto a master hard drive, updating, prepping
and then imaging that afterward with Composer. It's certainly less effort.

This goes hand-in-hand with my philosophy of installing a complete set of
software and then using scripts to customize the installation afterward.

Sorry for the long answer. I hope that explains it well.

[This would actually make for a great Casper User Group topic.]

--

bill

William M. Smith, Technical Analyst
MCS IT
Merrill Communications, LLC
(651) 632-1492

I don't think it was too long...very similar to how my responses get sometimes. =)

And I can agree that perhaps it is a good topic for a CUG, but I wanted to bring it up here as well because I think this is the perfect venue to share this information and what it was intended for. It helps educate us all on making the right decisions and using the right tools.

I assume that you still need to build this virgin image on the latest hardware? I don't have to make new OS images often so I've never really tried to improve the process.

When I tried to download InstaDMG from Sourceforge it wasn't available...=/

Thanks, Bill!

Craig E

On Wednesday 11/12/08 7:24 AM, "Ernst, Craig S." <ERNSTCS at uwec.edu> wrote: I don't think it was too long...very similar to how my responses get sometimes. =) And I can agree that perhaps it is a good topic for a CUG, but I wanted to bring it up here as well because I think this is the perfect venue to share this information and what it was intended for. It helps educate us all on making the right decisions and using the right tools.

Glad you found it useful. My verbosity is often parallel to my interest in
the subject.:-)

I assume that you still need to build this virgin image on the latest hardware? I don't have to make new OS images often so I've never really tried to improve the process.

I think the hardware issues where you wanted to build on the latest and
greatest machine in your fleet were primarily limited to Mac OS X 10.4.
That's why I'm only doing this with Leopard. But I couldn't find anything to
reinforce my thinking on this. Building on the latest Mac OS is more
important. The hardware of the machine doesn't come into play at all when
using InstaDMG.

When I tried to download InstaDMG from Sourceforge it wasn't available...=/

I think it's now completely on AFP548.com. This is the latest release
<http://www.afp548.com/article.php?story080916222225163&query=instadmg>.

Support is sparse and really only done through the AFP548.com forums. Lots
of folks are contributing their experiences, ideas and helper scripts. One
person has provided a CreateUser.pkg package that you can modify to create
that first user (probably your Casper admin user account) and others give
advice for preventing the startup movie. Things like that.

--

bill

William M. Smith, Technical Analyst
MCS IT
Merrill Communications, LLC
(651) 632-1492

Glad to hear that. I contacted JAMF Support first and received a reply that
On Tuesday 11/11/08 4:37 PM, "Steve Wood" <swood at integerdallas.com> wrote:
they really don't know InstaDMG that well. They asked me to post here.

What I'd be happy to know is the command that Casper uses to set the machine
name. Is it looking for a file that's not there? Or are they using a
built-in command like systemsetup, which is in different paths in 10.4 and
10.5? Even running that command doesn't set the Hostname, only the Computer
Name.

I'm sure I can work around the problem but that means I'll have to write an
extra script and populate one of the script variable fields in Casper
Imaging with the name. Easy to forget.

--

bill

William M. Smith, Technical Analyst
MCS IT
Merrill Communications, LLC
(651) 632-1492

I'm testing with the InstaDMG method too, in order to create the base OS
image to be used by Casper.
William described it pretty well. On the whole, it's intended to image a
complete system for end user deployment, but if you leave out the custom
software packages, you can use it quite well to generate a base image.

InstaDMG consists of a folder structure into which packages (and scripts
encapsulated in payload-free packages), an image of an OS installer disk,
and a script that assembles these pieces into a bootable image.

It installs the OS into an empty dmg file. Then installs the indicated
packages into that same DMG file, finally prepping the dmg for asr. It's
actually pretty similar to the manual assembly of scripts I was using for
deployment before I found Casper.

The benefits are a never-booted, customized, updated image. By installing
onto a target machine, tweaking that machine and then imaging with Composer
or some other disk imaging tool, you end up with user accounts (which you
can still add via the InstaDMG workflow or via Casper) and their associated
home folders, logs, caches, etc. I haven't done enough testing, but it is
my assumption that an InstaDMG image that was created with the latest OS X
combo updater ought to boot any Apple-supported system that isn't newer than
the combo updater.

The core methodologies of InstaDMG and Casper are very compatible, which is
one of the things that drew me to it.

There are materials and a discussion board for InstaDMG on afp548.com. Josh
Wisenbaker's held a webcast in April that explains the methodology and
benefits in detail. I'm not sure if afp548 have an archive of it, but if
you have access to Apple Sales Web, you can download the webcast archive via
iTunes.

If I understand correctly Casper will pull the machine name as it exists on Macintosh HD, if you were reimaging a machine that had a readable Macintosh HD partition, or it will pull the machine name from the data it has about that machine in the JSS. As far as the command it's using to do that I imagine the app is simply modifying a plist.

Not sure if it's just: Library -> Preferences -> SystemConfiguration -> com.apple.smb.server.plist

I see it changes the ServerDescription tag, but other than that I'm not sure.

Craig E

The test that the JAMF folks had me try was to use the jamf binary to
rename:

sudo jamf setComputerName -target "/Volumes/Macintosh HD/" -name "JAMF"

When we did that the name would not change in the Sharing Pref panel until
the machine was restarted. Once restarted the machine showed the new name,
JAMF in this case. We then tried using hostname to set the name, but this
not only did not change the Sharing pane but it also did not change on
restart.

I have had the problem on brand new machines, fresh out of the box, where I
have tried setting the name in Casper Imaging, or setting it to MAC or S/N.
Each time the machine comes up with no name and shows up in the JSS as
{Network {HostNames {.

2008/11/12 Steve Wood <swood at integerdallas.com>

The test that the JAMF folks had me try was to use the jamf binary to rename: sudo jamf setComputerName -target "/Volumes/Macintosh HD/" -name "JAMF" When we did that the name would not change in the Sharing Pref panel until the machine was restarted. Once restarted the machine showed the new name, JAMF in this case.

If you execute "hostname" after running this command, what is the output?

What about "scutil --get ComputerName"?

I ask because if the name is being changed, and it shows the new name in the
system tools that you will interact with, but you just don't see it in the
GUI until restart, is that really a problem?

I'm not finding that this is an appearance issue. The Computer Name doesn't
On 11/12/08 10:51 AM, "Miles Leacy" <miles.leacy at themacadmin.com> wrote:
get populated and the Hostname returns as "Macintosh.local".

I rely on Casper (or Casper Imaging) to enter the name during the time of
imaging a machine because we don't pre-populate our JSS with machine data
and pull names. If the machine name is not present on the computer after
imaging then Active Directory and Open Directory binding doesn't happen
correctly.

--

bill

William M. Smith, Technical Analyst
MCS IT
Merrill Communications, LLC
(651) 632-1492

After executing the jamf binary command, and then using hostname or scutil,
I still receive the old name of the computer. So, it appears that the jamf
command must write to a startup item that renames the computer. Again, upon
restart the name is changed.

No, it does not name it at startup for FirstRun, once the OS is laid down and the packages, it runs commands against Macintosh HD to name it before you boot to it. That would be why when you reboot you see the correct name.

Craig

And to be clear, the tests I’m running are on a system that is already
imaged and running, and issuing the commands from the terminal. I am not
laying down a new image on the machine.

This may have been said, but I have seen when imaging a machine that Casper does not seem to set all of the "computer names." What I mean by this is that you can set the computer name using scutil with three different locations, ComputerName, HostName, and LocalHostName. I don't remember exactly what each is used for, but in the past we've always wanted all of them to be set. I've found the most reliable solution for this is to run a script at reboot that does:

#!/bin/bash

computerName=$2

scutil -set ComputerName $computerName
scutil -set HostName $computerName
scutil -set LocalHostName $computerName

This is only a workaround, but reliably renames the computer. I've had issues where the computer just gets the name of the machine I built the base image on if I don't.

Ryan Harter
UW - Stevens Point
Workstation Developer
715.346.2716
Ryan.Harter at uwsp.edu

With the help of the folks at JAMF (thank you, Sam) I've created a simple
workaround to my problem.

The computer name is set by Casper at the end of imaging but before
rebooting to the imaged drive. At that point it is setting the Computer Name
and Hostname in:

/Library/Preferences/SystemConfiguration/preferences.plist

This preferences.plist file does not exist in an InstaDMG image. It is
created by the Apple Setup Assistant, which has never run. Without the
presence of this file Casper cannot set the names.

Our workaround is to package the preferences.plist file from an existing
machine and include it during the imaging process.

Copying the plist file from my MacBook Pro to a PowerMac MDD G4 leads me to
believe this should work for most machines but I haven't tested any further.

The preferences.plist file also includes your Network Locations settings,
which location is active and your active network interfaces. Be sure to set
these prior to packaging.

--

bill

William M. Smith, Technical Analyst
MCS IT
Merrill Communications, LLC
(651) 632-1492

Thanks for the info.
This does open up some more questions in search of a better solution...

The thought of manually building system configuration preferences takes the
wind out of my automation sails, metaphorically speaking. I don't like the
idea of bringing over another machine's plist either. It has potential for
cruft, which we're trying to eliminate with InstaDMG, and it makes the
assumption that we have a working machine to pull a plist from. We probably
do, but what if you're setting up a brand new site? I'd rather be able to
do this via scripting.

How does Apple Setup Assistant generate
the /Library/Preferences/SystemConfiguration/preferences.plist file? If it
uses defaults, then we can deploy a plist that only contains the computer
name and hostname keys, and let ASA handle the rest.

If the jamf binary can query the JSS, perhaps a script that gets the
computer name and host name from the JSS, and then performs "defaults write
/Volumes/yourtargetvolume/Library/Preferences/SystemConfiguration/preferences.plist
<appropriate keys & values>" would be possible.

What if, as part of the InstaDMG process, you include a script that executes
"touch
/Volumes/yourtargetvolume/Library/Preferences/SystemConfiguration/preferences.plist"? Will the existence of an empty file allow Casper to set the preferences?

Thanks,
Miles Leacy

Hi Miles!

Great questions!

This method is definitely a workaround and not a solution. I left out some
details to shorten my post but I'll include them here.

Just the presence of the file isn't enough so a touch command to create the
preferences.plist file doesn't work. I do believe that a "defaults write"
command with the proper properties would suffice.

In my testing, the extra properties controlling the network interfaces,
location, etc., must be present for binding to work. I originally removed
all the properties in the preferences.plist file except for the one for the
Computer Name and Hostname. While the other properties were re-written by
the Mac OS they apparently weren't done either quickly enough or in the
correct order of events to allow my script to bind to Open Directory.

Querying the JSS for the Computer Name does not meet my needs in my
environment. We don't pre-populate or pre-stage machines. I need to be able
to specify the name in the Casper or Casper Imaging application.

Keep in mind that the same file with the cruft from the original computer is
still there with an OS image created by Composer. In my opinion, I haven't
created any more than would already be there.

My hope is that the JAMF folks make some changes to accommodate for InstaDMG
OS files. (I'm assuming defaults write to create the file with minimum
properties is the way to go.) They have an interest and desire to make
things work for their customers, which I appreciate greatly.

--

bill

William M. Smith, Technical Analyst
MCS IT
Merrill Communications, LLC
(651) 632-1492