diff --git a/docs/textdocs/BROWSING-Config.txt b/docs/textdocs/BROWSING-Config.txt
index fa520731141..33c56e08975 100644
--- a/docs/textdocs/BROWSING-Config.txt
+++ b/docs/textdocs/BROWSING-Config.txt
@@ -39,12 +39,15 @@ the "remote browse sync" parameters to your smb.conf file.
 If only one WINS server is used then the use of the "remote announce" and the
 "remote browse sync" parameters should NOT be necessary.
 
-Thirdly, where Samba is used in a multi-workgroup environment, each workgroup
-MUST have it's own WINS server! Samba WINS is NOT capable of handling multiple
-workgroups. This means it that the only way to establish cross segment / cross
-workgroup browsing requires the use of a WINS server for each workgroup, then
-use "remote browse sync" and "remote announce" to affect browse list collation
-across all segments.
+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 redundency
+(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).
 
 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