Jump to content

OS X clients report as name.local


j-gray
 Share

Recommended Posts

Running the latest ERA Server and OS X agent. Active Directory environment, OS X devices are domain joined and DNS suffix is appended via DHCP option.

 

Many of the OS X devices show up as 'computername.local' instead of their fully qualified domain name (like Windows clients do).

 

Typing 'hostname' in terminal reports the workstation name with FQDN, so I'm not sure where the issue is.

 

This causes the system to appear twice in the ERA console; once as the .local and once as the FQDN (from AD sync). The AD sync'd version always shows offline and the .local as online.

 

I have the auto-renaming to FQDN task set to run hourly, but this does not resolve the issues. 

 

Any ideas how to get the clients to show up with proper hostname including FQDN?

 

 

Link to comment
Share on other sites

  • ESET Staff

Could you please check what is Mac client reporting in it's client details view - in section "Device identifiers"? The same data is actually used for automatic renaming using task you mentioned. Also in case you will be successful with renaming (even manual), consequent run of "AD/LDAP synchronization" task is required to remove offline duplicates - and task has to be configured for this.

Link to comment
Share on other sites

For reference, we've seen similar results in our environment.  Most Mac clients would show up in ERA with a ".local", while a few would show up with the FQDN.  We also had the added issue that some of our Macs were missing local configuration options, and while they would allow for Active Directory logins, their hostname (via command line) would not always match what was configured via the GUI, nor would they always show the FQDN.

 

The quickest workaround that I found to eliminate duplicate computer accounts in ERA for our Mac clients was to alter the task on the ERA server that renamed synchronized computers.  Instead of having it rename by FQDN, I switched it to just rename by Computer Name.  Under this configuration, we no longer have duplicate accounts for our Mac clients.  All of our Windows clients still show up in ERA by their FQDN, and the majority of our Mac clients now do too.  Only 27 of our Mac clients (approximately 16% of our reporting Mac population) show up with just a short name.  It may not be a 100% perfect solution, but it has eliminated our duplicate computer issues and given us a more accurate machine count.

Link to comment
Share on other sites

Could you please check what is Mac client reporting in it's client details view - in section "Device identifiers"?

In the Device Identifiers section, it reports the 'Computer name' correctly (name only). However, it reports the FQDN as computername.local

 

As zhopkins reported, it appears to be random whether they report their proper FQDN or just .local.

 

Also, I have a task to delete not connecting computers. I have another task to sync AD. So the first task removes the clients with FQDN because it thinks they're not connecting (when actually connecting as computer.local). Then the AD sync task brings those objects back into ERA because they exist in AD.

 

This would seem to be a bug or shortcoming with the product, no? Or is it working as designed?

Link to comment
Share on other sites

  • ESET Staff

It seems system is reporting FQDN with "local" in case computer is not in domain and local is considered as default. AGENT should not report such FQDN which would result automatically in use of computer name during renaming or initial creation of computer record in console. Key question is whether this computer is actually in domain? What do you expect in FQDN - the same as computer name or there is also missing domain name? Regardless of that I will try to check what method is used to fetch FQDN from system (most probably it is equivalent of hostname -f command line call). Both computer name and FQDN are resolved during AGENT startup and there is a chance that at that moment system is not joined into domain yet - could you please try to restart AGENT's service (without system reboot) and check whether client starts reporting correct FQDN? Service can be restarted from console using:

sudo launchctl stop com.eset.remoteadministrator.agent

As already mentioned, renaming task can be configured to use computer name instead of FQDN which may works as workaround for problematic computers. Unfortunately for initial computer name there is no workaround - either FQDN sent from AGENT or reverse DNS lookup will be used.

Link to comment
Share on other sites

Key question is whether this computer is actually in domain? What do you expect in FQDN

All workstations (Mac and Windows) are domain joined.

 

Domain suffix (search domains) and DNS servers are configured via DHCP server.

So workstation name is:  ws-osx-01

Domain suffix is:  contoso.com

FQDN should be reported as:  ws-osx-01.contoso.com

 

All of these systems resolve in DNS (forward and reverse) with the proper FQDN.  They've also rebooted multiple times, so the agent has been reset multiple times.

Link to comment
Share on other sites

  • ESET Staff

They've also rebooted multiple times, so the agent has been reset multiple times.

 

Actually rebooting will most probably won't help in case problem is with startup order. Not sure what "software" you are using to join domain on Mac OS X, but in case it starts later than AGENT, FQDN may be fetched before computer is actually joined into domain ... but that is only hypothesis.

 

Also it seems AGENT uses system calls that should be equivalent of output from scutil command line tool available from terminal. Could you please check output of these command on problematic client is possible?

scutil --get HostName
scutil --get LocalHostName
scutil --get ComputerName

so that we can check whether system is providing correct values to AGENT.

Link to comment
Share on other sites

 

They've also rebooted multiple times, so the agent has been reset multiple times.

 

Actually rebooting will most probably won't help in case problem is with startup order. Not sure what "software" you are using to join domain on Mac OS X, but in case it starts later than AGENT, FQDN may be fetched before computer is actually joined into domain ... but that is only hypothesis.

 

Also it seems AGENT uses system calls that should be equivalent of output from scutil command line tool available from terminal. Could you please check output of these command on problematic client is possible?

scutil --get HostName
scutil --get LocalHostName
scutil --get ComputerName

so that we can check whether system is providing correct values to AGENT.

 

 

We add them to the domain with the Directory Utility, which is native/built in to OS X workstations. This should not affect the computer name at all.

 

I ran the commands on systems reporting in with correct FQDN and systems reporting in as computername.local and got the same results for all:

HostName: not set

actualcomputername

actualcomputername

 

In all cases, the systems are reporting the correct computer name, just not appending the correct domain suffix consistently.

Link to comment
Share on other sites

  • ESET Staff

Just to update you on the progress, we have created a bug report based on your reports. Just out of curiosity, have you contacted ESET support regarding this matter, so we can theoretically link it to any open support case? Thank you.

Edited by MichalJ
Link to comment
Share on other sites

  • 2 weeks later...

Just to update you on the progress, we have created a bug report based on your reports. Just out of curiosity, have you contacted ESET support regarding this matter, so we can theoretically link it to any open support case? Thank you.

Thanks for the update.

 

I created a case a week ago (#1480064). They suggested the issue was caused by DNS reverse lookup (it is not). Otherwise, they suggested creating a Server Task to rename the clients to solve the issue. However, we already have this task running and it does not resolve the issue.

Link to comment
Share on other sites

  • 3 weeks later...

Just to update you on the progress, we have created a bug report based on your reports.

Could you please provide some more information on this?

 

I've been working with support, and so far they haven't indicated that this is a bug or a known issue. They're simply asking me to rename the hosts via command, which I don't feel is a solution.

Link to comment
Share on other sites

I'm finding that the workstations go back and forth between 'name + .local' and 'name + fqdn'.  I have no idea why it keeps changing.

 

Still going back and forth with support, but there's been no indication that this is a known bug.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...