9.3 Discussion | The Official Samba-3 HOWTO and Reference Guide, 2nd Edition

All MS Windows networking uses SMB-based messaging. SMB messaging may be implemented with or without NetBIOS. MS Windows 200x supports NetBIOS over TCP/IP for backwards compatibility. Microsoft appears intent on phasing out NetBIOS support.

9.3.1 NetBIOS over TCP/IP

Samba implements NetBIOS, as does MS Windows NT/200x/XP, by encapsulating it over TCP/IP. MS Windows products can do likewise. NetBIOS-based networking uses broadcast messaging to effect browse list management. When running NetBIOS over TCP/IP, this uses UDP-based messaging. UDP messages can be broadcast or unicast.

Normally, only unicast UDP messaging can be forwarded by routers. The remote announce parameter to smb.conf helps to project browse announcements to remote network segments via unicast UDP. Similarly, the remote browse sync parameter of smb.conf implements browse list collation using unicast UDP.

Secondly, in those networks where Samba is the only SMB server technology, wherever possible nmbd should be configured on one machine as the WINS server. This makes it easy to manage the browsing environment. If each network segment is configured with its own Samba WINS server, then the only way to get cross-segment browsing to work is by using the remote announce and the remote browse sync parameters to your smb.conf file.

If only one WINS server is used for an entire multi-segment network, then the use of the remote announce and the remote browse sync parameters should not be necessary.

As of Samba-3 WINS replication is being worked on. The bulk of the code has been committed, but it still needs maturation . This is not a supported feature of the Samba-3.0.0 release. Hopefully, this will become a supported feature of one of the Samba-3 release series.

Right now Samba WINS does not support MS-WINS replication. This means that when setting up Samba as a WINS server, there must only be one nmbd configured as a WINS server on the network. Some sites have used multiple Samba WINS servers for redundancy (one server per subnet) and then used remote browse sync and remote announce to effect browse list collation across all segments. Note that this means clients will only resolve local names, and must be configured to use DNS to resolve names on other subnets in order to resolve the IP addresses of the servers they can see on other subnets. This setup is not recommended, but is mentioned as a practical consideration (i.e., an " if all else fails " scenario).

Lastly, take note that browse lists are a collection of unreliable broadcast messages that are repeated at intervals of not more than 15 minutes. This means that it will take time to establish a browse list and it can take up to 45 minutes to stabilize, particularly across network segments.

9.3.2 TCP/IP without NetBIOS

All TCP/IP-enabled systems use various forms of host name resolution. The primary methods for TCP/IP hostname resolution involve either a static file ( /etc/ hosts ) or the Domain Name System (DNS). DNS is the technology that makes the Internet usable. DNS-based host name resolution is supported by nearly all TCP/IP-enabled systems. Only a few embedded TCP/IP systems do not support DNS.

When an MS Windows 200x/XP system attempts to resolve a host name to an IP address it follows a defined path :

Checks the hosts file. It is located in C:\Windows NT\System32\Drivers\etc .
Does a DNS lookup.
Checks the NetBIOS name cache.
Queries the WINS server.
Does a broadcast name lookup over UDP.
Looks up entries in LMHOSTS, located in C:\Windows NT\System32\Drivers\etc .

Windows 200x/XP can register its host name with a Dynamic DNS server. You can force register with a Dynamic DNS server in Windows 200x/XP using: ipconfig /registerdns .

With Active Directory (ADS), a correctly functioning DNS server is absolutely essential. In the absence of a working DNS server that has been correctly configured, MS Windows clients and servers will be unable to locate each other, so consequently network services will be severely impaired.

The use of Dynamic DNS is highly recommended with Active Directory, in which case the use of BIND9 is preferred for its ability to adequately support the SRV (service) records that are needed for Active Directory.

9.3.3 DNS and Active Directory

Occasionally we hear from UNIX network administrators who want to use a UNIX-based Dynamic DNS server in place of the Microsoft DNS server. While this might be desirable to some, the MS Windows 200x DNS server is auto-configured to work with Active Directory. It is possible to use BIND version 8 or 9, but it will almost certainly be necessary to create service records so MS Active Directory clients can resolve host names to locate essential network services. The following are some of the default service records that Active Directory requires:

_ldap._tcp.pdc.ms-dcs. Domain This provides the address of the Windows NT PDC for the Domain.

_ldap._tcp.pdc.ms-dcs. DomainTree Resolves the addresses of Global Catalog servers in the domain.

_ldap._tcp. site .sites.writable.ms-dcs. Domain Provides list of Domain Controllers based on sites.

_ldap._tcp.writable.ms-dcs. Domain Enumerates list of Domain Controllers that have the writable copies of the Active Directory datastore.

_ldap._tcp. GUID .domains.ms-dcs. DomainTree Entry used by MS Windows clients to locate machines using the Global Unique Identifier.

_ldap._tcp. Site .gc.ms-dcs. DomainTree Used by MS Windows clients to locate site configuration dependent Global Catalog server.