Skip to main content

Alternate Title: "Notes On Becoming More Familiar With How JSS Determines A Computer's Name"



RESULT SUMMARY: The output of `scutil --get ComputerName` needs to be set correctly before running `jamf recon` in order for the Computer Name in JSS not to be set incorrectly.



PROBLEM: Some of the names for computers in JSS do not match our organization's naming convention. Sometimes this happens to a machine that has been in the wild. Most of the time this happens immediately after imaging.



OBSERVATIONS: The incorrect name, when not caused by human error or abused admin rights, is invariably related to DNS. It is sometimes localhost and it is sometimes a name that can be found on our DNS.



Here are the results of some experimentation with a MacBook Air running OS X 10.8.3. By my convention, all CamelCase words indicate the value was derived from the scutil tool.



The initial settings were as follows:



Computer Name in JSS (v8.71): mylaptop
ComputerName: mylaptop
LocalHostName: mylaptop
HostName: mylaptop
FQDN for laptop's IP: foo-test.example.com.
IP of FQDN: 10.101.3.108



On the laptop I verified that my machine had the same HostName, LocalHostName, and ComptuerName as outputted by scutil. It also had the same entry in JSS verified through the web interface.



On the DNS server I created foo-test.example.com A and PTR records for the IP address being handed out to my test laptop's Ethernet port. Airport was turned off.



In other words, DNS returned a different name than the names set on the laptop.



After rebooting, this is what I found:



$ networksetup -getinfo "USB Ethernet" | grep "^IP address"

IP address: 10.101.3.108

$ host 10.101.3.108

foo-test.example.com.

$ host foo-test.example.com

10.101.3.108

$ hostname

mylaptop

$ scutil --get ComputerName

mylaptop

$ scutil --get HostName

mylaptop

$ scutil --get LocalHostName

mylaptop


When I ran `sudo jamf recon, the JSS record did not change. When I changed HostName to "", then results of the hostname` command become the FQDN name, which didn't match the ComputerName.



$ sudo scutil --set HostName ""

$ scutil --get HostName

HostName: not set

$ hostname

foo-test.example.com


NOTE: The results of `hostname` do not always match HostName. There are FOUR DIFFERENT names a Mac OS X computer can have. (Anyone know why?)



When I ran recon with the HostName set to "", JSS kept the same Computer Name.



So far everything behaved as expected. So how does the name in JSS get changed to an undesired name?



I then set the ComputerName and LocalHostName to "", and set HostName to "mylaptop-hostname". Upon reboot ComputerName and LocalHostName were still "" and HostName was "mylaptop-hostname". When I ran `jamf recon` the JSS Computer Name changed to "mylaptop-hostname". Now we are getting somewhere.



When I set all three names to "", the FQDN became the output of `hostname. When I ran recon, Computer Name was set to hostname`.



I also discovered why some computers were getting named "localhost". If the IP address did not return a FQDN when checked in DNS, then `hostname` was set to "localhost" which consequently made its way to the JSS.



CONCLUSION: Recon uses ComputerName if available, then HostName, and finally `hostname` to update the Computer Name field in JSS. At some point in the imaging process, the computer is checking into JSS without having a ComputerName or HostName set. This results in FQDN being used if the network is available or localhost if it is not.



PROPOSED SOLUTION: Set the ComputerName, HostName and LocalHostName to the same thing and set them before the network is activated.



What is the best way to accomplish that? Under old UNIX it would /etc/hostconfig or in /etc/hosts, but those are depreciated files in OS X. Daniel handles it by deleting stuff in SystemConfiguration/preferences.plist and com.apple.smb.server.plist then letting the post imaging scripts set the name.



RELATED THEADS:



I ran into this issue a while ago, and I explicitly set HostName, ComputerName, and LocalHostName using scutil before binding the system to the domain (I do all of our domain binding in a custom app since I am not allowed to use service accounts for binding, no audit trail). I have not run into any issues with this setup, systems no longer grab the name from DNS.



Since users often change the share name (ComputerName) to something arbitrary, I created an extension attribute for HostName which is usually accurate, but of course some users mess with that as well.



I could write the real name to a plist at imaging time and pull that into the extension attribute and then have a policy reset everything with scutil, I suppose. So far it hasn't been a problem for us.

I tested ```
sudo jamf setComputerName
``` (v8.71) and it sets ComputerName, LocalHostName, and HostName. So in theory, the first command of the Enroll/enroll.sh script should lock in the computers name.



The LaunchDaemon for this script is set to run every 300 seconds. Once it gets a positive connection to JSS via the `jamf checkJSSConnection` command, it does its enroll stuff and cleans itself up.



Could something be happening between the setComputerName and the recon step that is renaming the computer?

Looking at SystemConfiguration/preferences.plist on a newly imaged machine before it boots for the first time, it seems like Casper Imaging is doing the right thing. Every field with the template computer's name has been changed to the imaged computer name.



Next step is to try and catch a mis-named computer event early enough to see how it differs from these successful naming events.

I noticed a difference between `sudo jamf setComputerName` and running `sudo scutil --set ComputerName`. The former, while it updates three of the names (ComputerName, HostName, and LocalHostName), it does not update SystemConfiguration/com.apple.smb.server.plist. The scutil naming tool does update the "ServerDescription" key to the same value as ComputerName.



I also noticed, that the value returned by `hostname` is the only name that gets set when `/etc/hostconfig` has a "hostname=" entry.



At this point, I don't think the `jamf setComputerName` nor the Casper Imaging tool handle all the possible cases to ensure the proper name is set on first boot.



The beginning of Enroll/enroll.sh can be changed to the following: ```
newname="mycomputer"
scutil --set ComputerName $newname
scutil --set LocalHostName $newname
scutil --set HostName $newname
grep -q "hostname=" /etc/hostconfig 2> /dev/null || echo "hostname=$newname" >> /etc/hostconfig
```
This would only work for the boot disk, as no targets are set, but that is not a problem for enroll.sh. This script names all three names defined in SystemConfiguration/preferences.plist. It sets the name in com.apple.smb.server.plist. And it overrides the "automatic" system Apple has in place for the output of `hostname`, a system that has known failure modes in certain DNS configurations.

Is there any risk in changing ComputerName and/or LocalHostName without also confirming Computer ID (the name used when joining to domain)? :)



Our asset management folks are using scripts we created to target misnamed Macs. Unjoin, purge, bounce service, rename, rejoin with correct name. Just need to make sure the account used to do this has rights to join existing object in AD (just in case).



We usually don't tinker with HostName, instead we let AD [mis]handle that.



Do

I've been thinking pre-AD binding during the enroll process, but you are correct that there is yet another name that needs to be tracked.



The answer to your question is yes, there is some risk in changing the local computer's names to something different than the Computer ID (or Computer Account as named by dsconfigad). Unfortunately, I have not been able to reproduce this on the workbench. I have had cases where local admin users change the name of their computer and then the RADIUS server denies them access to the network or no new AD accounts can be created on their Mac. Changing the name back to bound name works every time to correct the problem.



Don, do you use JAMF's "rename computer to what is in JSS" feature or did you roll your own scripts?

I would like to resurrect the topic if possible. I am running into this exact issues as been stated above. The clients that have been imaged and enrolled with JSS are getting bounce messages about hostname already exists and changes itself. DHCP is setup to handle by MAC address, DNS has no entries that would cause a replication of the hostname. It sounds like I need to ensure their names are explicit. Since I've already deployed, I would need to run scutil on the machines which would be tedious.
Could someone help with making the script to query their computername and then replicate that name for Hostname and localHostname?

@rcuza



Don, do you use JAMF's "rename computer to what is in JSS" feature or did you roll your own scripts?


I'm sorry, I didn't get an alert when you posted your question last year. We've always rolled our own, since there were many steps involved in unbinding, deleting the object from AD, and rebinding with the correct name. I'm not a script expert, not sure how they handled the script having the service account that was used to delete the bad AD object.

Reply


Terms & ConditionsCookie settings