I am having the same issue.
my only resolution was to clear out the saved authentication on the computers tab, then quit out of ARD, then forcequit ard agent, then re-add the computers to the auth'd computer tab and all is well until the IP changes again.
to workaround the issue we set our DHCP server to a 1 month lease time and only have to do the above once a month.
with 3.7 apple tried to accomodate machines with multiple NIC cards with multiple IP's and it has backfired.
- Support for OS X Mavericks
- Automatic copy and paste between local and remote computers
- Improved support for Mac systems with multiple displays and multiple IP addresses
- Enhanced multi-observe with gesture support for swiping between screens
I'm experiencing this annoying problem too... I have browsed all over and nobody seems to know what to do to fix it.... I've alwys been a Mac person and I'm very dissapointed for the last week as I cannot do anything after this upgrade...
Please someone inform them - I have tried it as well and could not find a right category for this on bugreporter.
Hoping for a solution soon.....
I called Apple support today. The tech assured me that they were looking into it as it was a known defect. He asked about subnetting, switches, and LAN layout. We're not doing anything too exotic here, so no lightbulb moment. However, he did seem suprised that I mentioned DHCP as a possible culprit. To his knowledge, there is no fix (although the extension of DHCP lease time is a good idea). He did recommend using a 10.8 machine with 3.6 ARD. To me that's not a fix, that's an excuse. Anyways, keep an eye out for a patch...sometime.
I am running OS 10.9 and just downgraded to ARD 3.6.1 Admin and 3.6 Client. Everything is back to normal. I did not have to downgrade client machines.
I installed ARD3.6.1 admin and client on the admin machine using pacifist.
Not sure what the upgrades were in 3.7 but I can live without them.
Just my two cents.
AdminDesktop is named AdminDesktop.local for mDNS. It is running 10.9.1 with the IP of 1.57 Yet ARD reports it as BS9.local with version 3.7.1. Meanwhile BS9 has the correct IP and mDNS name. I verified that alll mDNS names are unique and per machine. When I click on AdminDesktop, I get BS9's screen. Going on to scutil, the machine HostName isn't set at all. I was under the impression that was set automagically via the Sharing control panel. After setting LocalHostName, Hostname, and ComputerName to AdminDesktop and reinstalling ARD, same result: clicking on AdminDesktop brings up BS9. I'm genuinely stuck.
Yes but you have multiple machines called BS9.local in DNS, and you may have multiple other names in DNS (I have no idea how long your list is there).
I suspect what Apple have done in 3.7+ is to switch to DNS hostname as the primary name resolution method, meaning that the DNS must be in good standing. I've been dealing with this issue today and noticed that we had over 30+ hosts with the same DNS hostname in ARD for some reason, even though they have individual names. I also recently resolved an issue which was preventing our Macs from registering in Active Directory DNS, which I suspect has caused the problem.
If I wipe out the plist file and start again, it's ok. If I restore the plist, I'm back to machines oscilating between offline / online / IP addresses changing etc.
Export your main computer list, convert it into xml (with plutil -convert xml1 [computerlist.plist]) and look at it - it might shed some light as to what is going on.
Further to this - what I have done:
Backed up the com.apple.RemoteDesktop.plist file from
...then copied it to a Mac running XCode.
I've converted the plist to xml using:
plutil -convert xml1 com.apple.RemoteDesktop.plist
Loaded it into XCode, and converted all the 'hostnames' fields to type 'string' instread of 'array' (NOTE: there are 'hostname' and hostnames' (plural) - the 'hostnameS' were often array type).
Re-converted the plist back to binary using:
plutil -convert binary1 com.apple.RemoteDesktop.plist
...moved it back into
We still have some wrong hostnames, but it's behaving itself a lot better.
"I suspect that what Apple have done . . . is to switch to DNS hostname as the primary name resolution method"
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.
You can't change a Mac's multicast nature without hobbling/breaking the OS in a major way.
". . . meaning that DNS must be in good standing"
Especially so with Macs but should be the case regardless. As we know PCs are a lot more forgiving and less sensitive to sloppy DNS than Macs are although even Microsoft with Windows7 and now Windows8 are fine-tuning this even more that these newer OSes are not that dissimilar to OS X.
"I . . . recently resolved an issue . . . preventing Macs from registering in Active Directory DNS . . ."
To be precise Active Directory itself does not 'do' DNS. The Windows Server that's presumably acting as the Domain Controller is. One of the 'problems' most network administrators have in dealing with Macs on a network is they (wrongly) assume the macs respond to it in the same way PCs do. They don't. PCs are DDNS (dynamic DNS) aware on the forward pointer. Out of the box macs are not. They're DDNS aware on the reverse pointer. What this means is if an IP address has already been handed out to a PC on the same network then the DNS service will assign that PC an rDNS record in the reverse zone for that subnet based on its local name and appended domain name. If the same IP address is subsequently handed to a Mac it will use the existing rDNS record that's already there.
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.
This can and does cause problems when binding macs to Active Directory as well as result in (in some cases) incomplete or failed logins that are random and seemingly difficult to fix.
A number of ways of stopping this behaviour is to either create static entries in the DHCP and DNS services for affects Macs or alter the default scavenging interval for stale records in the DNS service. 1-2 days usually works for me.
There are other effective ways of accommodating Macs on a 'Windows' network but the above do work well in my experience.
If Macs end up with multiple names there is a potential connectivity issues when using ARD. I've seen the problem posters are reporting on this forum since 3.7's release in earlier versions for this very reason. 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. None of us have any way of knowing they will because Apple have always been consistent in never letting anyone know what they're planning with anything they do.