Regenerate

(This used to be commit 25db62e3101dbcae8e9daee3cb16430297afa223)

1 files changed, 60 insertions, 38 deletions

diff --git a/docs/htmldocs/browsing-quick.html b/docs/htmldocs/browsing-quick.html
index 680bdfc1de..aa3dba2ee4 100644
--- a/docs/htmldocs/browsing-quick.html
+++ b/docs/htmldocs/browsing-quick.html
@@ -5,7 +5,7 @@
 >Quick Cross Subnet Browsing / Cross Workgroup Browsing guide</TITLE
 ><META
 NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.77+"><LINK
+CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
 REL="HOME"
 TITLE="SAMBA Project Documentation"
 HREF="samba-howto-collection.html"><LINK
@@ -81,21 +81,24 @@ be taken as the fast track guide to implementing browsing across subnets
 and / or across workgroups (or domains). WINS is the best tool for resolution
 of NetBIOS names to IP addesses. WINS is NOT involved in browse list handling
 except by way of name to address mapping.</P
+><P
+>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.</P
 ><DIV
 CLASS="SECT1"
 ><H1
 CLASS="SECT1"
 ><A
-NAME="AEN230"
-></A
->2.1. Discussion</H1
+NAME="AEN130"
+>2.1. Discussion</A
+></H1
 ><P
 >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.</P
+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.</P
 ><P
 >Normally, only unicast UDP messaging can be forwarded by routers. The
 "remote announce" parameter to smb.conf helps to project browse announcements
@@ -109,18 +112,23 @@ segment is configured with it's 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.</P
 ><P
->If only one WINS server is used then the use of the "remote announce" and the
-"remote browse sync" parameters should NOT be necessary.</P
+>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.</P
 ><P
->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).</P
+>As of Samba-3 WINS replication is being worked on. The bulk of the code has
+been committed, but it still needs maturation.</P
+><P
+>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).</P
 ><P
 >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
@@ -132,9 +140,9 @@ CLASS="SECT1"
 ><H1
 CLASS="SECT1"
 ><A
-NAME="AEN238"
-></A
->2.2. Use of the "Remote Announce" parameter</H1
+NAME="AEN139"
+>2.2. Use of the "Remote Announce" parameter</A
+></H1
 ><P
 >The "remote announce" parameter of smb.conf can be used to forcibly ensure
 that all the NetBIOS names on a network get announced to a remote network.
@@ -190,9 +198,9 @@ CLASS="SECT1"
 ><H1
 CLASS="SECT1"
 ><A
-NAME="AEN252"
-></A
->2.3. Use of the "Remote Browse Sync" parameter</H1
+NAME="AEN153"
+>2.3. Use of the "Remote Browse Sync" parameter</A
+></H1
 ><P
 >The "remote browse sync" parameter of smb.conf is used to announce to
 another LMB that it must synchronise it's NetBIOS name list with our
@@ -213,9 +221,9 @@ CLASS="SECT1"
 ><H1
 CLASS="SECT1"
 ><A
-NAME="AEN257"
-></A
->2.4. Use of WINS</H1
+NAME="AEN158"
+>2.4. Use of WINS</A
+></H1
 ><P
 >Use of WINS (either Samba WINS _or_ MS Windows NT Server WINS) is highly
 recommended. Every NetBIOS machine registers it's name together with a
@@ -267,22 +275,23 @@ CLASS="emphasis"
 CLASS="EMPHASIS"
 >DO NOT EVER</I
 ></SPAN
-> use both "wins support = yes" together with "wins server = a.b.c.d"
-particularly not using it's own IP address.</P
+> 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!</P
 ></DIV
 ><DIV
 CLASS="SECT1"
 ><H1
 CLASS="SECT1"
 ><A
-NAME="AEN268"
-></A
->2.5. Do NOT use more than one (1) protocol on MS Windows machines</H1
+NAME="AEN169"
+>2.5. Do NOT use more than one (1) protocol on MS Windows machines</A
+></H1
 ><P
 >A very common cause of browsing problems results from installing more than
 one protocol on an MS Windows machine.</P
 ><P
->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
@@ -298,6 +307,19 @@ interface over the IPX protocol. Samba will then lose the LMB role as Windows
 as an LMB and thus browse list operation on all TCP/IP only machines will
 fail.</P
 ><P
+><SPAN
+CLASS="emphasis"
+><I
+CLASS="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.</I
+></SPAN
+></P
+><P
 >The safest rule of all to follow it this - USE ONLY ONE PROTOCOL!</P
 ></DIV
 ><DIV
@@ -305,9 +327,9 @@ CLASS="SECT1"
 ><H1
 CLASS="SECT1"
 ><A
-NAME="AEN274"
-></A
->2.6. Name Resolution Order</H1
+NAME="AEN177"
+>2.6. Name Resolution Order</A
+></H1
 ><P
 >Resolution of NetBIOS names to IP addresses can take place using a number
 of methods. The only ones that can provide NetBIOS name_type information