Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Apple Remote Desktop 3.7 Displays Multiple IPs

Hi,


I'm running Apple Remote Desktop 3.7 on 10.9. Ever since the update, I've had very hit or miss success in using the program as intended. ARD seems to think that up to 5 machines have the same IP. DHCP on our server isn't handing out the same IP to multiple machines, so why does ARD mark it as such? It is really problematic when I click on a machine to help and a different machine is contacted. Is there a setting somewhere to lock on to MAC addresses or force a flush of the database? Thanks for any help!

User uploaded file

MacBooks, iMacs, Xserves, etc, Mac OS X (10.6.8)

Posted on Nov 15, 2013 12:52 PM

Reply
23 replies

Dec 3, 2013 8:18 AM in response to Russell Lindenschmidt

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


Dec 3, 2013 9:19 AM in response to Russell Lindenschmidt

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.....

Dec 3, 2013 9:47 AM in response to Russell Lindenschmidt

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.

Jan 17, 2014 9:08 AM in response to Paul Fitz

Sorry, not quite following. By host names, do you mean the multicast DNS name (.local) or HostName set via scutil? Even then, check the screenshot out:User uploaded file

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.

Jan 17, 2014 9:24 AM in response to Russell Lindenschmidt

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.

Jan 17, 2014 10:05 AM in response to Paul Fitz

Further to this - what I have done:


Quit ARD.


Backed up the com.apple.RemoteDesktop.plist file from


/Users/admin/Library/Containers/com.apple.RemoteDesktop/Data/Library/Preferences /com.apple.RemoteDesktop.plist


...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


/Users/admin/Library/Containers/com.apple.RemoteDesktop/Data/Library/Preferences


Re-run ARD.


We still have some wrong hostnames, but it's behaving itself a lot better.

Jan 17, 2014 10:25 AM in response to Paul Fitz

Hi


"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.


HTH?


Tony

Jan 17, 2014 11:29 AM in response to Antonio Rocco

>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:


<dict>

<key>hardwareAddress</key>

<string>c8:2a:14:xx:xx:xx</string>

<key>hostname</key>

<string>c02fnz6xxxxx.xxxx.yyyy.zzzz.uk</string>

<key>name</key>

<string>C02FNZ6xxxxx</string>

<key>networkAddress</key>

<string>192.168.1.63</string>

<key>networkPort</key>

<integer>3283</integer>

<key>preferHostname</key>

<true/>

<key>vncPort</key>

<integer>5900</integer>

</dict>


>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.

Apple Remote Desktop 3.7 Displays Multiple IPs

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.