Macs Computer Names Doubling

[plex 2]

We upgraded from Server 6.4 to 6.5 and started seeing about 5% of the Macs with their names displaying doubled, eg. hostname hostname.  Some seem to have strange path names in the computer name.  Not all Macs have been updated to 6.5 Agent and 6.5 Endpoint Security.  There are both upgraded and not upgraded Macs with the doubling issue.  I've tried deleting a Mac from the Console and when it reports again, it has it's name doubled again.

Server 6.5.522.0
Web Console 6.5.388.0
EES for macOS 6.5.600.1/6.5.376.0
Remote Agent 6.5.376.0/6.4.246.0

Below are Macs that show the name doubling.  Also the last one has some weird path in the name that isn't part of the machine name.

Since this has occurred with both Macs that have been updated to Agent 6.5 and ones still on 6.4, and it didn't begin until the Server upgrade, seems like it's related to the upgrade.

Is there a fix I can do for this or will it require a ticket to be opened?

[plex 2]

Several Macs have the \266\128\153 in the name.  Appears to be a single quote.  U+2019 RIGHT SINGLE QUOTATION MARK, 0xE2 0x80 0x99 in hexadecimal, or 226 128 153 in decimal.

So that explains what that part is, but not why it's displaying that way.

[MartinK 378]

Could you please check, what "Device identifiers" are reported wit these devices when you open client details of problematic device?

Also it would help us to know where does the computer name come from as there are few possibilities:

• if you you installed AGENT on machine that was not previously known to ERA, new entry in Lost&Found group was created either by name sent from client computer, or by reverse DNS resolving
• have you synchronized computer names from AD/LDAP before AGENT deployment?
• are you using "Computer rename" task to automatically rename computers to value reported as "Device identifier"

From my point of view it is encoding problem, but not sure what is the source, as we have not seen such problem ever.

[plex 2]

• The Device Identifier has the doubling as well.
  
• We have a hourly rename task.  It ran 15 minutes prior to the above screenshot.
• Rename is based on Computer FQDN.
• Active Directory sync runs hourly as well.

We are going to try uninstalling Agent and Endpoint Security and reinstalling to see if it will resolve.  We found that when we deleted the computer from the console, it reconnected with the same GUID.  The trace.log showed that no data needed updating after it saw the deleted machine had the same GUID so the computer name still was doubled.

 

[MartinK 378]

11 minutes ago, plex said:

We are going to try uninstalling Agent and Endpoint Security and reinstalling to see if it will resolve.  We found that when we deleted the computer from the console, it reconnected with the same GUID.  The trace.log showed that no data needed updating after it saw the deleted machine had the same GUID so the computer name still was doubled.

 

Thanks for details. It seems to be issue somewhere in AGENT's FQDN detection. I will have to check what method for further analysis.

Regarding removing computers from console - I would not recommend to do that. It won't help in this case, and there is a possibility that by deleting you lost some data, which it may take some time (even a day) until it is recovered.

Is this something that started recently or you have not deployed AGENTs on macOS previously? Asking because there has been an system update for macOS which may be cause of this in case it worked previously.

[plex 2]

This occurred immediately after upgrading the server from 6.4 to 6.5.  All the machines with this issue should have had both the Agent and Endpoint Security before the upgrade took place.

Sorry for being unclear.  We discovered the removing from the console was not a good idea already.  So I wasn't planning on doing that again.  But, because removing from the console wasn't a good idea, we want to try uninstalling both the Agent and EES and then reinstall again.  Hopefully it will generate a new GUID and we'll see if this was caused by the upgrade process or due to still existing issue.  We won't be able to do this until tomorrow since we have to coordinate with an affected user.  I'll report back the results once we're able to uninstall/reinstall.

[MartinK 378]

Could you please run following script on client machine? It is similar to the one used to fetch FQDN on client machine:

#!/usr/bin/env sh -xe

PATH=$PATH:/usr/sbin

computername="$(scutil --get ComputerName)"
if test -n "$computername"
then
  fqdn="$(nslookup "$computername" | grep -E "^Name:" | awk '{print $2}')"
  test -n "$fqdn" && echo $fqdn && exit 0
fi

sysctl kern.hostname | grep -E "^kern\.hostname\:" | awk '{print $2}'

an also output of:

locale

just to check what encoding is machine using when scripts.

 

Regarding re-installation, it will use new UUID. There is also possibility to run "Reset cloned agent" task on one specific client, which will reset its UUID. Be aware that this task will be never marked as finished in console, but you will know it worked once client appears in Lost&found group.

[plex 2]

Here's the results:

testmac.example.com testmac.example.com
testmac.example.com

Here's locale:

LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL=

If this is similar to the method that is being used by the server, then we know why we are getting these results.

Here is the NSLOOKUP results from the test machine:

testmac.example.com:~ username$ nslookup testmac.example.com
Name:   testmac.example.com
Address: 10.0.0.163
Name:   testmac.example.com
Address: 192.168.1.34

Since it's grepping anything with "^Name:", what ends up happening, for whatever reason (multiple adapters, DNS/router with old DNS entries), the script will return multiple names for one machine.  We have one machine that apparently is getting 4 IP addresses reported from NSLOOKUP on their home router.  So it has the name quadrupled in our ERA console.

Another issues is that some home routers will use the WAN side for DNS results.  This means that a machine outside of our company network may show the NSLOOKUP DNS results for the public IP address of the router (we also have seen this with our Macs).  For example, we have a Mac named dhcp-1x-1xx-x4-1xx.wireless.northwestern.private right now.  It also explains why special characters like the single quotes and spaces getting converted into decimal code.  Probably due to what's happening with the script when translating the non-standard characters that a Mac will allow.

We suspect you've had customers complain that their Macs (and maybe Linux) machines are not matching up with their LDAP/AD syncs.  Since a Mac has 3 separate possible names for the same computer, and ComputerName is always set, you're using ComputerName as the primary choice for a Mac.  Since this name typically doesn't (and probably shouldn't) have the DNS suffix, you're using NSLOOKUP to try and get the DNS suffix for a Mac.  This is a tough situation, we wished Apple would make this more robust.  Trying to get the DNS suffix from NSLOOKUP is unreliable.  You may get more than one DNS result, which result do you choose?  If the Mac reports back to your server and it's not on your company network, NSLOOKUP won't return the correct domain suffix.

As you can see from our results above, we are setting our Mac's HostName to include our DNS suffix.  We suggest you have a setting we can put in a policy to have the Mac clients use HostName as the primary name.  Since the HostName is not set by default and may be blank, you could then fallback to using the ComputerName instead.  Then, if we see a Mac that does not have the LDAP/AD name with the domain suffix, we can verify and fix the HostName on that Mac.  You could then recommend to ERA customers that they populate the HostNames of their Macs to include the domain suffix so that it will match up during a LDAP/AD sync and results will be much more reliable than trying to guess the DNS suffix as you're having to do now.

[MartinK 378]

Thanks for example data and analysis. We will have to take o look at it and it will be reported as issue. Script is definitely not correct -> it would be better to not report domain suffix, as to report unreliable data.

As a workaround I would recommend to create new "Computer renaming task" configured to use ComputerName instead of FQDN and assign it to macOS computers (i.e. on dynamic group for this operating system type).

[plex 2]

If we do a rename task using ComputerName, the Active Directory sync won't match up.  If HostName was an option in the rename task, it would work because we have the FQDN set as the HostName.  Then the AD sync will match up correctly.  So if you gathered HostName as a Device Identifier on a Mac, you could add HostName as an option in the rename task which will make getting a FQDN to match up with an AD sync much more reliable.  Or, at least something a company using LDAP/AD has a chance for a more reliable method of getting FQDN.

Also, we can't use FQDN as the ComputerName because it would be confusing.  If someone were to see a ComputerName is SAMPLE.EXAMPLE.COM, most people would think they could ping just SAMPLE.  But that wouldn't work, they would have to ping SAMPLE.EXAMPLE.COM instead.  I doubt most people would even think to do that.  Also, a NSLOOKUP would might then result in SAMPLE.EXAMPLE.COM.EXAMPLE.COM, or in the case of a home router or different domain, something like SAMPLE.EXAMPLE.COM.OTHER-DOMAIN.COM.