Put in documentation update by jht

(This used to be commit 38424c522ab2ddbf6d6c61274d692b14e574023a)

3 files changed, 94 insertions, 54 deletions

diff --git a/docs/docbook/projdoc/Browsing-Quickguide.sgml b/docs/docbook/projdoc/Browsing-Quickguide.sgml
index 8e3fbce6d3..0a5cf72038 100644
--- a/docs/docbook/projdoc/Browsing-Quickguide.sgml
+++ b/docs/docbook/projdoc/Browsing-Quickguide.sgml
@@ -1,9 +1,10 @@
 <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>
@@ -16,16 +17,22 @@ of NetBIOS names to IP addesses. WINS is NOT involved in browse list handling
 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>
@@ -45,20 +52,27 @@ the "remote browse sync" parameters to your smb.conf file.
 </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>
@@ -198,8 +212,9 @@ To configure Samba to register with a WINS server just add
 </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>
@@ -213,7 +228,7 @@ one protocol on an MS Windows machine.
 </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
@@ -232,6 +247,15 @@ as an LMB and thus browse list operation on all TCP/IP only machines will
 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>
diff --git a/docs/docbook/projdoc/Browsing.sgml b/docs/docbook/projdoc/Browsing.sgml
index 13d6fce917..aeb3b477c5 100644
--- a/docs/docbook/projdoc/Browsing.sgml
+++ b/docs/docbook/projdoc/Browsing.sgml
@@ -27,8 +27,15 @@ document.
 </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.
@@ -40,14 +47,10 @@ 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>
@@ -68,12 +71,12 @@ that is providing this service.
 
 <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>
@@ -113,6 +116,15 @@ connection that lists the shares is done as guest, and thus you must
 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
@@ -132,7 +144,7 @@ in smb.conf)
 <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
@@ -167,8 +179,7 @@ settings) for Samba this is in the smb.conf file.
 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>
@@ -419,9 +430,9 @@ in the [globals] section add the line
 </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>
 
@@ -473,7 +484,7 @@ machine or its IP address.
 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 = &gt;name&lt;</command>" option then
+"<command>wins server = &lt;name&gt;</command>" option then
 nmbd will fail to start.
 </para>
 
@@ -538,11 +549,12 @@ server, if you require.
 <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>
@@ -594,7 +606,7 @@ you must not set up a Samba server as a domain master browser.
 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&gt;1B&lt;) with WINS instead of the PDC.
+browser NetBIOS name (DOMAIN&lt;1B&gt;) with WINS instead of the PDC.
 </para>
 
 <para>
@@ -661,8 +673,8 @@ samba systems!)
 </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>
diff --git a/docs/docbook/projdoc/GroupProfiles.sgml b/docs/docbook/projdoc/GroupProfiles.sgml
index e5120aed9b..8bdf98059a 100644
--- a/docs/docbook/projdoc/GroupProfiles.sgml
+++ b/docs/docbook/projdoc/GroupProfiles.sgml
@@ -14,7 +14,7 @@
 	</author>
 </chapterinfo>
 
-<title>Creating Group Profiles</title>
+<title>Creating Group Prolicy Files</title>
 
 <sect1>
 <title>Windows '9x</title>
@@ -34,7 +34,7 @@ stuff. You then save these settings in a file called
 <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>
@@ -42,19 +42,23 @@ All of this is covered in the Win98 Resource Kit documentation.
 </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>