Automatic FQDN rename not working

[j-gray 35]

This task has been configured to run on the 'Lost and Found' container for quite a while and has been working. The task still runs successfully, but we have 60+ Mac's that are not updating their FQDN. The show as hostname only.

They reply/resolve on the network with their FQDN. They are in DNS and DHCP with their correct FQDN.

Why does ESMC not show their correct FQDN and what can I do to resolve this issue?

[MartinK 378]

Seems that in ESMC 7.0 hostname and FQDN are both extracted from value that can be fetch via command line:

sysctl kern.hostname

Could you verify what value it returns in your environment? There seems to be no "standard" way how to configure macOS after it is joined into domain and this detection seems to work for all users

In previous versions there was also alternative implementation that used reverse-DNS but it results in issues reported by other customers and could possibly lead in reporting completely invalid data -> it was depending on network configuration.

 

[j-gray 35]

5 hours ago, MartinK said:

Seems that in ESMC 7.0 hostname and FQDN are both extracted from value that can be fetch via command line:

sysctl kern.hostname

Could you verify what value it returns in your environment? There seems to be no "standard" way how to configure macOS after it is joined into domain and this detection seems to work for all users

In previous versions there was also alternative implementation that used reverse-DNS but it results in issues reported by other customers and could possibly lead in reporting completely invalid data -> it was depending on network configuration.

 

Thanks for the reply.

That command returns the hostname only.

How do we get the client to properly report FQDN?

The problem is that this creates two objects when using AD sync: one object with FQDN and the same object with hostname only. The object with hostname only then gets dumped into Lost & Found.

The rename task used to work in the past. We have too many clients to rename every duplicate manually. Is there a workaround?

 

[j-gray 35]

Is there a recommended solution for this issue?

[j-gray 35]

I've opened a case with support (312404) to see what we can do to resolve this issue.

[MartinK 378]

Is there any known method you are already using to fetch FQDN on those machines? For example some command line tool, shell command, etc.? Does output of any of following command:

hostname
hostname -f
scutil --get ComputerName
scutil --get HostName
scutil --get LocalHostName
sysctl -a

mention value that could be possibly used as FQDN?

We have already seen machines that were configured in a way that they were not aware of their's FQDN, it was available only on DNS servers, but that is problem for ESMC Agent which requires data to be available locally.

[j-gray 35]

4 hours ago, MartinK said:

Is there any known method you are already using to fetch FQDN on those machines? For example some command line tool, shell command, etc.? Does output of any of following command:

hostname
hostname -f
scutil --get ComputerName
scutil --get HostName
scutil --get LocalHostName
sysctl -a

mention value that could be possibly used as FQDN?

We have already seen machines that were configured in a way that they were not aware of their's FQDN, it was available only on DNS servers, but that is problem for ESMC Agent which requires data to be available locally.

No specific method. Domain is provided by DHCP option to all clients. This value is returned via ifconfig on any OS X client.

While the commands above typically return just the hostname, the 'sysctl kern.hostname' returns either just the hostname, or in some cases the FQDN. I don't know how kern.hostname gets set.

I can set kern.hostname to the value of the FQDN. In this case, HostName remains as just the hostname (no FQDN). But in this case, I believe I have to uninstall/reinstall the agent for the client to then report the new FQDN properly.

[MartinK 378]

42 minutes ago, j-gray said:

I can set kern.hostname to the value of the FQDN. In this case, HostName remains as just the hostname (no FQDN). But in this case, I believe I have to uninstall/reinstall the agent for the client to then report the new FQDN properly.

Value of kern.hostname should be actually used by AGENT so setting it should resolve problem. There is definitely no need to reinstall AGENT -> hostname is not fetched very often, so easiest would be to restart AGENT's service. It can be done using following commands in root terminal:

cd "/Applications/ESET Remote Administrator Agent.app"
./Contents/Scripts/restart_agent.sh

 

[j-gray 35]

Thanks for the info.  Any idea why the 'Rename Computers' task no longer renames these clients?

 

Restart agent command gave the following and did not seem to do anything:

//Contents/Resources/com.eset.remoteadministrator.agent_daemon.plist: No such file or directory
//Contents/Resources/com.eset.remoteadministrator.agent_daemon.plist: No such file or directory
//Contents/Resources/com.eset.remoteadministrator.restart_agent.plist: No such file or directory

[j-gray 35]

From support; developers thought it was a reverse lookup issue. From statement above, it would seem like reverse lookup is no longer used by ESET.

Once I demonstrated that reverse lookup was functioning properly, support pretty much told me I'd need to figure it out.

Can anyone clarify how the 'Rename' task based on FQDN is supposed to work?

Thank you.

[MartinK 378]

1 hour ago, j-gray said:

From support; developers thought it was a reverse lookup issue. From statement above, it would seem like reverse lookup is no longer used by ESET.

Once I demonstrated that reverse lookup was functioning properly, support pretty much told me I'd need to figure it out.

Can anyone clarify how the 'Rename' task based on FQDN is supposed to work?

Thank you.

Task mechanisms is very simple -> it takes FQND of machine as reported to ESMC and changes device name in console to be exactly value of hostname that is reported as FQDN.

Crucial in this case is what ESMC Agent is reporting to ESMC as FQDN. This can be shown in console in client details view in device identifiers section:

as "Computer FQDN". Until this value is not corrected, renaming task won't behave correctly.

As I mentioned previously, ESMC 7.0 Agents are not using any kind of reverse-DNS lookups, they just ask operating system for it's FQDN. In case system does not report correct value (or it is missconfigured, or it does not even have knowledge of it's FQDN), there is no way around, except disabling renaming task for those devices and rename them manually to match entries in domain.