<chapter id="Browsing-Quick">
<chapterinfo>
<author>
- <firstname>John</firstname><surname>Terpstra</surname>
+ <firstname>John H</firstname><surname>Terpstra</surname>
</author>
<pubdate>July 5, 1998</pubdate>
+ <pubdate>Updated: March 15, 2003</pubdate>
</chapterinfo>
<title>Quick Cross Subnet Browsing / Cross Workgroup Browsing guide</title>
except by way of name to address mapping.
</para>
+<para>
+Note: MS Windows 2000 and later can be configured to operate with NO NetBIOS
+over TCP/IP. Samba-3 and later also supports this mode of operation.
+</para>
+
+
<sect1>
<title>Discussion</title>
<para>
Firstly, all MS Windows networking is based on SMB (Server Message
-Block) based messaging. SMB messaging is implemented using NetBIOS. Samba
-implements NetBIOS by encapsulating it over TCP/IP. MS Windows products can
-do likewise. NetBIOS based networking uses broadcast messaging to affect
-browse list management. When running NetBIOS over TCP/IP this uses UDP
-based messaging. UDP messages can be broadcast or unicast.
+Block) based messaging. SMB messaging may be implemented using NetBIOS or
+without NetBIOS. Samba implements NetBIOS by encapsulating it over TCP/IP.
+MS Windows products can do likewise. NetBIOS based networking uses broadcast
+messaging to affect browse list management. When running NetBIOS over
+TCP/IP this uses UDP based messaging. UDP messages can be broadcast or unicast.
</para>
<para>
</para>
<para>
-If only one WINS server is used then the use of the "remote announce" and the
-"remote browse sync" parameters should NOT be necessary.
+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.
</para>
<para>
-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 affect 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 (ie: an 'if all else fails' scenario).
+As of Samba-3 WINS replication is being worked on. The bulk of the code has
+been committed, but it still needs maturation.
+</para>
+
+<para>
+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 affect 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 (ie: an 'if all else fails' scenario).
</para>
<para>
</para>
<para>
-<emphasis>DO NOT EVER</emphasis> use both "wins support = yes" together with "wins server = a.b.c.d"
-particularly not using it's own IP address.
+<emphasis>DO NOT EVER</emphasis> use both "wins support = yes" together
+with "wins server = a.b.c.d" particularly not using it's own IP address.
+Specifying both will cause nmbd to refuse to start!
</para>
</sect1>
</para>
<para>
-Every NetBIOS machine take part in a process of electing the LMB (and DMB)
+Every NetBIOS machine takes part in a process of electing the LMB (and DMB)
every 15 minutes. A set of election criteria is used to determine the order
of precidence for winning this election process. A machine running Samba or
Windows NT will be biased so that the most suitable machine will predictably
fail.
</para>
+<para><emphasis>
+Windows 95, 98, 98se, Me are referred to generically as Windows 9x.
+The Windows NT4, 2000, XP and 2003 use common protocols. These are roughly
+referred to as the WinNT family, but it should be recognised that 2000 and
+XP/2003 introduce new protocol extensions that cause them to behave
+differently from MS Windows NT4. Generally, where a server does NOT support
+the newer or extended protocol, these will fall back to the NT4 protocols.
+</emphasis></para>
+
<para>
The safest rule of all to follow it this - USE ONLY ONE PROTOCOL!
</para>
</para>
<para>
-Browsing will NOT work if name resolution from NetBIOS names to IP
-addresses does not function correctly. Use of a WINS server is highly
+MS Windows 2000 and later, as with Samba-3 and later, can be
+configured to not use NetBIOS over TCP/IP. When configured this way
+it is imperative that name resolution (using DNS/LDAP/ADS) be correctly
+configured and operative. Browsing will NOT work if name resolution
+from SMB machine names to IP addresses does not function correctly.
+</para>
+
+<para>
+Where NetBIOS over TCP/IP is enabled use of a WINS server is highly
recommended to aid the resolution of NetBIOS (SMB) names to IP addresses.
WINS allows remote segment clients to obtain NetBIOS name_type information
that can NOT be provided by any other means of name resolution.
<title>Browsing support in samba</title>
<para>
-Samba now fully supports browsing. The browsing is supported by nmbd
+Samba facilitates browsing. The browsing is supported by nmbd
and is also controlled by options in the smb.conf file (see smb.conf(5)).
-</para>
-
-<para>
Samba can act as a local browse master for a workgroup and the ability
-for samba to support domain logons and scripts is now available. See
-DOMAIN.txt for more information on domain logons.
+for samba to support domain logons and scripts is now available.
</para>
<para>
<para>
[Note that nmbd can be configured as a WINS server, but it is not
-necessary to specifically use samba as your WINS server. NTAS can
-be configured as your WINS server. In a mixed NT server and
-samba environment on a Wide Area Network, it is recommended that
-you use the NT server's WINS server capabilities. In a samba-only
-environment, it is recommended that you use one and only one nmbd
-as your WINS server].
+necessary to specifically use samba as your WINS server. MS Windows
+NT4, Server or Advanced Server 2000 or 2003 can be configured as
+your WINS server. In a mixed NT/2000/2003 server and samba environment on
+a Wide Area Network, it is recommended that you use the Microsoft
+WINS server capabilities. In a samba-only environment, it is
+recommended that you use one and only one Samba server as your WINS server.
</para>
<para>
have a valid guest account.
</para>
+<para><emphasis>
+MS Windows 2000 and upwards (as with Samba) can be configured to disallow
+anonymous (ie: Guest account) access to the IPC$ share. In that case, the
+MS Windows 2000/XP/2003 machine acting as an SMB/CIFS client will use the
+name of the currently logged in user to query the IPC$ share. MS Windows
+9X clients are not able to do this and thus will NOT be able to browse
+server resources.
+</emphasis></para>
+
<para>
Also, a lot of people are getting bitten by the problem of too many
parameters on the command line of nmbd in inetd.conf. This trick is to
<sect1>
<title>Browsing across subnets</title>
<para>
-With the release of Samba 1.9.17(alpha1 and above) Samba has been
+Since the release of Samba 1.9.17(alpha1) Samba has been
updated to enable it to support the replication of browse lists
across subnet boundaries. New code and options have been added to
achieve this. This section describes how to set this feature up
Cross subnet browsing is a complicated dance, containing multiple
moving parts. It has taken Microsoft several years to get the code
that achieves this correct, and Samba lags behind in some areas.
-However, with the 1.9.17 release, Samba is capable of cross subnet
-browsing when configured correctly.
+Samba is capable of cross subnet browsing when configured correctly.
</para>
<para>
</para>
<para>
-Versions of Samba previous to 1.9.17 had this parameter default to
+Versions of Samba prior to 1.9.17 had this parameter default to
yes. If you have any older versions of Samba on your network it is
-strongly suggested you upgrade to 1.9.17 or above, or at the very
+strongly suggested you upgrade to a recent version, or at the very
least set the parameter to 'no' on all these machines.
</para>
Note that this line MUST NOT BE SET in the smb.conf file of the Samba
server acting as the WINS server itself. If you set both the
"<command>wins support = yes</command>" option and the
-"<command>wins server = >name<</command>" option then
+"<command>wins server = <name></command>" option then
nmbd will fail to start.
</para>
<para>
Next, you should ensure that each of the subnets contains a
machine that can act as a local master browser for the
-workgroup. Any NT machine should be able to do this, as will
-Windows 95 machines (although these tend to get rebooted more
-often, so it's not such a good idea to use these). To make a
-Samba server a local master browser set the following
-options in the [global] section of the smb.conf file :
+workgroup. Any MS Windows NT/2K/XP/2003 machine should be
+able to do this, as will Windows 9x machines (although these
+tend to get rebooted more often, so it's not such a good idea
+to use these). To make a Samba server a local master browser
+set the following options in the [global] section of the
+smb.conf file :
</para>
<para>
By default, a Windows NT Primary Domain Controller for a Domain
name is also the Domain master browser for that name, and many
things will break if a Samba server registers the Domain master
-browser NetBIOS name (DOMAIN>1B<) with WINS instead of the PDC.
+browser NetBIOS name (DOMAIN<1B>) with WINS instead of the PDC.
</para>
<para>
</para>
<para>
-A "os level" of 2 would make it beat WfWg and Win95, but not NTAS. A
-NTAS domain controller uses level 32.
+A "os level" of 2 would make it beat WfWg and Win95, but not MS Windows
+NT/2K Server. A MS Windows NT/2K Server domain controller uses level 32.
</para>
<para>The maximum os level is 255</para>
</author>
</chapterinfo>
-<title>Creating Group Profiles</title>
+<title>Creating Group Prolicy Files</title>
<sect1>
<title>Windows '9x</title>
<filename>Config.POL</filename> that needs to be placed in
the root of the [NETLOGON] share. If your Win98 is configured to log onto
the Samba Domain, it will automatically read this file and update the
-Win98 registry of the machine that is logging on.
+Win9x/Me registry of the machine that is logging on.
</para>
<para>
</para>
<para>
-If you do not do it this way, then every so often Win98 will check the
+If you do not do it this way, then every so often Win9x/Me will check the
integrity of the registry and will restore it's settings from the back-up
-copy of the registry it stores on each Win98 machine. Hence, you will notice
-things changing back to the original settings.
+copy of the registry it stores on each Win9x/Me machine. Hence, you will
+occasionally notice things changing back to the original settings.
</para>
+<para>
+The following all refers to Windows NT/200x profile migration - not to policies.
+We need a separate section on policies (NTConfig.Pol) for NT4/200x.
+</para>
</sect1>
<sect1>
<title>Windows NT 4</title>
<para>
-Unfortunately, the Resource Kit info is Win NT4/2K version specific.
+Unfortunately, the Resource Kit info is Win NT4 or 200x specific.
</para>
<para>
git.samba.org / jra / samba / .git / commitdiff