Jump to content

Archived

This topic is now archived and is closed to further replies.

j-gray

Automatic FQDN rename not working

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites
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?

 

Share this post


Link to post
Share on other sites

Is there a recommended solution for this issue?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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:

image.png

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.

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...