Computer renaming doesn't stick in some cases

[rstasel]

Hi Everyone,

I have a very weird issue. I've been rolling out Casper to many of my clients, and using it to fix long standing naming errors with the machines (offices have changed, etc).

The issue is, some of the machines, no matter how many times I go into the JSS and change the name, rather than the name being changed on the client, it seems like they push their old name back to the JSS on their next check-in.

I'm using a policy to set the computer name, btw. It is enforced an all computers, all users.

What the heck!? We're on 9.93, btw.

Help?

[jgwatson]

I am seeing the same issue, but I am on 9.96.

[stevewood]

@staze if you want the name of the machine to always be what is in the JSS, you'll need to enforce the names during inventory. Find your "Update Inventory" policy in your JSS and make sure you have "Reset Computer Names" checked on the Maintenance tab:

[mpermann]

@staze I ran into inconsistent behavior in the past using the built-in Reset Computer Name functionality so I just run the one liner below to do it from the Files & Processes payload. Basically I have a simple policy that I use as a template. I clone the policy, change Template to the name I need the computer set to then I scope it to the computer and let the policy happen on the next recurring checkin. It's worked well for me.

scutil --set ComputerName 'Template';jamf recon

[rstasel]

I am doing it via maintenance. So I have to force an inventory at the same time?

I may have stumbled on a fix, though I'm unsure if it's legit. I set the policy to be ongoing, and trigger "reoccurring check-in". I previously had it set to run once a day.

If I have to force an inventory, then I'll probably just set the computer name update to happen at the same time as our weekly inventory.

[rstasel]

Yup, moved back to once a day, because doing it "reoccuring" and ongoing resulted in some rather large log files. =l

Please advise. Is there any way to find out of this is a known "bug"?

[rstasel]

Yup, moved back to once a day, because doing it "reoccuring" and ongoing resulted in some rather large log files. =l

Please advise. Is there any way to find out of this is a known "bug"?

[mpermann]

@staze the only way to know if it's a bug or not would be to contact your JAMF buddy/TAM. Unless your end users are in the habit of changing the computer name, the one liner I mentioned about will work for you. But it is a bit of a manual process. But once you get everything named correctly you shouldn't have to worry about it except for those instances where an end user manually changes it.

[cruess]

We have a mac mini and a few macbooks that have renamed themselves over 1000 times. Our JAMF rep said it was a DNS issue, but was unable to get it to stop.

The Jamf inventory entry shows ----> OSX-MacMini (4196) ----It's been renamed that many times.....
the mac mini is on the desk next to me and literally has never been renamed by human hands... lol

admin’s MacBook Pro (7)

etc....

This is really obnoxious.. we have the naming checked in management.. again, even our rep couldn't help on this one.. any pointers? Is there something to modify on the client side?? Or is this a JAMF issue?

[mpermann]

@cruess is the Mac Mini connected to your network via ethernet and WiFi? What version of the OS are you using? I seem to remember something about the computer having naming issues with certain versions of the OS. I've never experienced the issue myself but i think it's tied to the Bonjour protocol but I'm not certain.

[cruess]

@mpermann No, the mini is connected LAN only. All info for the eth0 connection is manual and accurate.