>You may or may not know this but Macs are first and foremost multicast unlike PCs which are unicast. Macs will always try Bonjour (.local) first and then move onto DNS, TCP/IP and whatever else is in the network stack. Hence the reason why you should avoid basing local/private DNS services around a .local TLD.
ARD sometimes prefers DNS hostname:
>If the PC is named laptop100 and the Mac is named iMac012 the rDNS record won't be updated automatically and the Mac may/will have an identity crisis because it can't resolve itself correctly. Namely it's name may resolve to its IP address but its IP address wont resolve to its name.
If you are using Windows DHCP service to assign IP addresses (which I am) then it will automatically update the DNS (forward and reverse) for addresses it assigns. You can either allow unsecured updates, or set an account with appropriate permissions within the DHCP service.
>Granted 3.7 does seem to be more sensitive to network instabilities caused by sloppy DNS/DHCP than previous versions but hopefully Apple will provide an update soon that stabilisies this version to the level of previous ones
I don't think they will because I suspect the problem is with DNS hostname issues resulting in a poisoned plist (see above) rather than a fundamental problem with ARD, however I have noticed 3.7 prefering DNS hostname. I suspect this is a change to facilitate larger deployments.
Just to correct an earlier post for clarification - I said the image listing 102 hostnames for the same system was from an export of a computer list - this is incorrect. It was the contents of the main ARD plist located here:
Antonio Rocco wrote:
You may or may not know this but Macs are first and foremost multicast unlike PCs which are unicast. Macs will always try Bonjour (.local) first and then move onto DNS, TCP/IP and whatever else is in the network stack. Hence the reason why you should avoid basing local/private DNS services around a .local TLD.
Actually since 10.6:
"Host names that contain only one label in addition to local, for example "My-Computer.local", are resolved using Multicast DNS (Bonjour) by default. Host names that contain two or more labels in addition to local, for example "server.domain.local", are resolved using a DNS server by default."
And as for avoiding a .local TLD:
"Additionally, Mac OS X v10.6 automatically detects when the local network operator has set up a name server that will answer name requests for a domain ending in ".local". It does this by checking to see if there is a Start Of Authority (SOA) record for the top level domain "local", which is how a DNS server indicates that it claims to have authority over a part of the DNS namespace. As long as the DNS server is properly configured with the required SOA record, Mac OS X v10.6 will detect this SOA record and automatically use this server to look up all host names in the domain."
I'm aware of these support articles but in practice I very rarely see (if any) networks that take any of this into account. Besides Apple's own implementation of mDNS is not perfect either and even host names that contain two or more labels in addition to .local still cause login problems as well as other random and inexplicable issues.
One thing is for certain you won't ever see a wholly mac-based network environment using it and if you tried it would sooner rather than later die on its feet although I doubt it would ever get off the ground in the first place.
I appear to have resolved this issue for our deployment by performing the following:
Take backup of: /Users/admin/Library/Containers/com.apple.RemoteDesktop/Data/Library/Preferences /com.apple.RemoteDesktop.plist
...then load the original into XCode's property list editor.
I manually checked every computer item for multiple 'hostnames' entries, and multiple 'networkAddresses'. In all cases where multiples were observed (dozens in some cases) I simply deleted the entries. It's apparently safe to delete all entries under 'hostnames' (plural) and 'networkAddresses' leaving the singular 'hostname' and 'networkAddress' entries alone (unless the 'hostname' was conflicting with another, in which case I replaced it with the machine name, followed by our fully qualified internal DNS name).
Also kept an eye out for wrong 'hostname' - in our database quite a few systems had a particular same 'hostname' for some reason (which wasn't even a Mac); those records typically had many multiple entries for hostname and networkAddresses.
Save the file and load ARD.
Now I am able to actually use ARD again - machines are responding and I am able to copy items, execute commands etc.
This does fix the problem. What I noticed is that the hostname for many of our machines were the same meanning machine-123.company.local was the hostname for most of my machines. The odd thing is that the hostname was certainly not the original host name that it was added with to ARD as I have deleted the pref for the app and reset all settings and readded everything. I have also cleared DNS and DHCP info before with no luck on fixing it.
Now I just wonder if someone can put a script together to look at the plist file and drop "networkaddresses" and "hostnames" then check "hostname" string and make it match the "name" plus the "company.local".