OS X: Can't Resolve Windows Machine Names [closed]

Question

I'm running a mixed environment at home and at work. My server machines are Win Vista, and I have a Unibody Macbook Pro running 10.5.7

On my mac, I can ping some home windows by name (If I use the full name such as stallion-main.local), but other machines, I can't.

My machines get dynamic ips from DHCP, so I can't edit the hosts file on the mac, or rather I want to avoid that solution.

It's a PITB when I try to RDP from my mac into my windows machine; as I have to log into my router to determine the ip address of windows machines that I can't resolve their name.

I'm not sure why some names resolve, while others do not.

Help me obi-wan-serverfault, you're my only hope.

Answer 1

Why not install Bonjour onto the Windows machines?

Answer 2

On the Mac turn on Windows file-sharing. That will then activate Samba on the Mac, and lets it query NetBIOS names directly. It seems to configure WINS correctly, automatically, although irritatingly hidden. With the sharing on, most Windows operations seems to work easier.

In 10.5 it's under Sys Prefs -> Sharing -> File Sharing -> Options <10.5 it's Sys Prefs -> Sharing -> Windows File Sharing

Answer 3

I have noticed a similar problem with .local domains under ubuntu - perhaps the same trick will work on a mac?

This is what I did:

• Edit /etc/nsswitch.conf
• change the order of the hosts: line so that dns comes before any mdns4 entries

• my line ends up being like:

  hosts: files dns mdns4_minimal mdns4

Answer 4

The reason why it's working on some Windows machines and not others is likely because you've got Bonjour installed on some of those machines without knowing it. Many versions of iTunes quietly install Bonjour, and the machine is then able to be found via .local.

The best fix is to just download the Windows Bonjour installer from Apple and run it on each Windows machine. That will also allow all the Windows machines to use .local addresses for any Apple client as well as for all Windows clients.

Answer 5

Windows name-resolution problems like this tend to be the result of the machines not being in the same workgroup. If all of your machines are in the same workgroup they should be able to browse and talk to each other. Without control of your local DNS environment, this is probably the easiest way to make it work.

Answer 6

Perhaps as a viable workaround: DHCP can be configured to always give the same IP to a host when it connects. "The same host" is defined by the MAC address. Even most routers have a setting that allows you to do this. This will save you the pain of trying to figure out the IP address.

Answer 7

Apparently there is no equivalent of nsswitch.conf in OSX.

as Brent mentioned, in Ubuntu you would install winbind and add "wins" to that conf file.

I did a lot of digging and here is the dead end:

http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/972003839731/inc/1

+1 for Brent

Answer 8

Im running Yosemite and I can use the 'smbutil' command to do WINS lookups

$ smbutil lookup revo
Got response from 192.168.0.2
IP address of revo: 192.168.0.2

Answer 9

If your boxes are using mDNS (multicast DNS / zeroconf dns system, see wikipedia/RFCs for details), possible culprits are:

• Ensure that all your computers are within the .local domain, I'm not sure if it's part of the specification or not, but the name resolution "stacks" I've come across have only passed .local names to the mDNS resolvers, and the rest went to dns and/or hostsfile.
• The service responsible for replying to mDNS queries don't have the appropriate services running.
• The firewall software running on the computers that don't resolve are blocking either the mDNS queries and/or replies.

The reason it sounds like mDNS is that you specifically mention that you need to query by their full name which includes .local. To check if it's actually mDNS you could try querying the nameserver(s) listed in /etc/hosts directly with i.e. tools like dig, host or nslookup and see if they give you any sensible response.

If it turns out not to be name-resolution by mDNS, let us know which dhcpd and dns/named you're running, check their logs and see if they provide any indication to why some of the names for the dhcp-leases haven't been registered in dns.