Very large number of markup fixes, layout updates, etc.
[samba.git] / docs / docbook / projdoc / NetworkBrowsing.xml
1 <chapter id="NetworkBrowsing">
2 <chapterinfo>
3         &author.jht;
4         <pubdate>July 5, 1998</pubdate>
5         <pubdate>Updated: April 21, 2003</pubdate>
6 </chapterinfo>
7
8 <title>Samba / MS Windows Network Browsing Guide</title>
9
10 <para>
11 This document contains detailed information as well as a fast track guide to
12 implementing browsing across subnets and / or across workgroups (or domains).
13 WINS is the best tool for resolution of NetBIOS names to IP addesses. WINS is
14 NOT involved in browse list handling except by way of name to address resolution.
15 </para>
16
17 <note><para>
18 MS Windows 2000 and later can be configured to operate with NO NetBIOS 
19 over TCP/IP. Samba-3 and later also supports this mode of operation.
20 When the use of NetBIOS over TCP/IP has been disabled then the primary
21 means for resolution of MS Windows machine names is via DNS and Active Directory.
22 The following information assumes that your site is running NetBIOS over TCP/IP.
23 </para></note>
24
25 <sect1>
26 <title>Features and Benefits</title>
27
28 <para>
29 Someone once referred to the past in terms of: <emphasis>They were the worst of times,
30 they were the best of times. The more we look back, them more we long for what was and
31 hope it never returns!</emphasis>.
32 </para>
33
34 <para>
35 For many MS Windows network administrators that statement sums up their feelings about
36 NetBIOS networking precisely. For those who mastered NetBIOS networking it's fickle
37 nature was just par for the course. For those who never quite managed to tame it's
38 lusty features NetBIOS is like Paterson's Curse.
39 </para>
40
41 <para>
42 For those not familiar with botanical problems in Australia: Paterson's curse,
43 Echium plantagineum, was introduced to Australia from Europe during the mid-nineteenth
44 century. Since then it has spread rapidly. The high seed production, with densities of
45 thousands of seeds per square metre, a seed longevity of more than seven years, and an
46 ability to germinate at any time of year, given the right conditions, are some of the
47 features which make it such a persistent weed.
48 </para>
49
50 <para>
51 In this chapter we explore vital aspects of SMB (Server Message Block) networking with
52 a particular focus on SMB as implmented through running NetBIOS (Network Basic
53 Input / Output System) over TCP/IP. Since Samba does NOT implement SMB or NetBIOS over
54 any other protocols we need to know how to configure our network environment and simply
55 remember to use nothing but TCP/IP on all our MS Windows network clients.
56 </para>
57
58 <para>
59 Samba provides the ability to implement a WINS (Windows Internetworking Name Server)
60 and implements extensions to Microsoft's implementation of WINS. These extensions
61 help Samba to affect stable WINS operations beyond the normal scope of MS WINS.
62 </para>
63
64 <para>
65 Please note that WINS is exclusively a service that applies only to those systems
66 that run NetBIOS over TCP/IP. MS Windows 200x / XP have the capacity to turn off
67 support for NetBIOS, in which case WINS is of no relevance. Samba-3 supports this also.
68 </para>
69
70 <para>
71 For those networks on which NetBIOS has been disabled (ie: WINS is NOT required)
72 the use of DNS is necessary for host name resolution.
73 </para>
74
75 </sect1>
76
77 <sect1>
78 <title>What is Browsing?</title>
79
80 <para>
81 To most people browsing means that they can see the MS Windows and Samba servers
82 in the Network Neighborhood, and when the computer icon for a particular server is
83 clicked, it opens up and shows the shares and printers available on the target server.
84 </para>
85
86 <para>
87 What seems so simple is in fact a very complex interaction of different technologies.
88 The technologies (or methods) employed in making all of this work includes:
89 </para>
90
91 <simplelist>
92         <member>MS Windows machines register their presence to the network</member>
93         <member>Machines announce themselves to other machines on the network</member>
94         <member>One or more machine on the network collates the local announcements</member>
95         <member>The client machine finds the machine that has the collated list of machines</member>
96         <member>The client machine is able to resolve the machine names to IP addresses</member>
97         <member>The client machine is able to connect to a target machine</member>
98 </simplelist>
99
100 <para>
101 The samba application that controls/manages browse list management and name resolution is
102 called <filename>nmbd</filename>. The configuration parameters involved in nmbd's operation are:
103 </para>
104
105 <para><programlisting>
106                 <!--FIXME-->
107         Browsing options:
108         -----------------
109                 * os level
110                   lm announce
111                   lm interval
112                 * preferred master
113                 * local master
114                 * domain master
115                   browse list
116                   enhanced browsing
117
118         Name Resolution Method:
119         -----------------------
120                 * name resolve order
121
122         WINS options:
123         -------------
124                   dns proxy
125                   wins proxy
126                 * wins server
127                 * wins support
128                   wins hook
129 </programlisting></para>
130
131 <para>
132 For Samba the WINS Server and WINS Support are mutually exclusive options. Those marked with
133 an '*' are the only options that commonly MAY need to be modified. Even if not one of these
134 parameters is set nmbd will still do it's job.
135 </para>
136
137 </sect1>
138
139 <sect1>
140 <title>Discussion</title>
141
142 <para>
143 Firstly, all MS Windows networking uses SMB (Server Message Block) based messaging.
144 SMB messaging may be implemented with or without NetBIOS. MS Windows 200x supports
145 NetBIOS over TCP/IP for backwards compatibility. Microsoft are intent on phasing out NetBIOS
146 support.
147 </para>
148
149 <sect2>
150 <title>NetBIOS over TCP/IP</title>
151
152 <para>
153 Samba implements NetBIOS, as does MS Windows NT / 200x / XP, by encapsulating it over TCP/IP.
154 MS Windows products can do likewise. NetBIOS based networking uses broadcast messaging to
155 affect browse list management. When running NetBIOS over TCP/IP this uses UDP based messaging.
156 UDP messages can be broadcast or unicast.
157 </para>
158
159 <para>
160 Normally, only unicast UDP messaging can be forwarded by routers. The
161 <command>remote announce</command> parameter to smb.conf helps to project browse announcements
162 to remote network segments via unicast UDP. Similarly, the 
163 <command>remote browse sync</command> parameter of <filename>smb.conf</filename>
164 implements browse list collation using unicast UDP.
165 </para>
166
167 <para>
168 Secondly, in those networks where Samba is the only SMB server technology
169 wherever possible <filename>nmbd</filename> should be configured on one (1) machine as the WINS
170 server. This makes it easy to manage the browsing environment. If each network
171 segment is configured with it's own Samba WINS server, then the only way to
172 get cross segment browsing to work is by using the 
173 <command>remote announce</command> and the <command>remote browse sync</command>
174 parameters to your <filename>smb.conf</filename> file.
175 </para>
176
177 <para>
178 If only one WINS server is used for an entire multi-segment network then
179 the use of the <command>remote announce</command> and the 
180 <command>remote browse sync</command> parameters should NOT be necessary.
181 </para>
182
183 <para>
184 As of Samba 3 WINS replication is being worked on. The bulk of the code has
185 been committed, but it still needs maturation. This is NOT a supported feature
186 of the Samba-3.0.0 release. Hopefully, this will become a supported feature
187 of one of the samba-3 release series.
188 </para>
189
190 <para>
191 Right now samba WINS does not support MS-WINS replication. This means that
192 when setting up Samba as a WINS server there must only be one <filename>nmbd</filename>
193 configured as a WINS server on the network. Some sites have used multiple Samba WINS
194 servers for redundancy (one server per subnet) and then used 
195 <command>remote browse sync</command> and <command>remote announce</command>
196 to affect browse list collation across all segments. Note that this means clients
197 will only resolve local names, and must be configured to use DNS to resolve names
198 on other subnets in order to resolve the IP addresses of the servers they can see
199 on other subnets. This setup is not recommended, but is mentioned as a practical
200 consideration (ie: an 'if all else fails' scenario).
201 </para>
202
203 <para>
204 Lastly, take note that browse lists are a collection of unreliable broadcast
205 messages that are repeated at intervals of not more than 15 minutes. This means
206 that it will take time to establish a browse list and it can take up to 45
207 minutes to stabilise, particularly across network segments.
208 </para>
209
210 </sect2>
211
212 <sect2>
213 <title>TCP/IP - without NetBIOS</title>
214
215 <para>
216 All TCP/IP using systems use various forms of host name resolution. The primary
217 methods for TCP/IP hostname resolutions involves either a static file (<filename>/etc/hosts
218 </filename>) or DNS (the Domain Name System). DNS is the technology that makes
219 the Internet usable. DNS based host name resolution is supported by nearly all TCP/IP
220 enabled systems. Only a few embedded TCP/IP systems do not support DNS.
221 </para>
222
223 <para>
224 When an MS Windows 200x / XP system attempts to resolve a host name to an IP address
225 it follows a defined path:
226 </para>
227
228 <orderedlist>
229         <listitem><para>
230         Checks the <filename>hosts</filename> file. It is located in
231         <filename>C:\WinNT\System32\Drivers\etc</filename>.
232         </para></listitem>
233
234         <listitem><para>
235         Does a DNS lookup
236         </para></listitem>
237
238         <listitem><para>
239         Checks the NetBIOS name cache
240         </para></listitem>
241
242         <listitem><para>
243         Queries the WINS server
244         </para></listitem>
245
246         <listitem><para>
247         Does a broadcast name lookup over UDP
248         </para></listitem>
249
250         <listitem><para>
251         Looks up entries in LMHOSTS. It is located in
252         <filename>C:\WinNT\System32\Drivers\etc</filename>.
253         </para></listitem>
254 </orderedlist>
255
256 <para>
257 Windows 200x / XP can register it's host name with a Dynamic DNS server. You can
258 force register with a Dynamic DNS server in Windows 200x / XP using:
259 <command>ipconfig /registerdns</command>
260 </para>
261
262 <para>
263 With Active Directory (ADS), a correctly functioning DNS server is absolutely
264 essential. In the absence of a working DNS server that has been correctly configured
265 MS Windows clients and servers will be totally unable to locate each other,
266 consequently network services will be severely impaired.
267 </para>
268
269 <para>
270 The use of Dynamic DNS is highly recommended with Active Directory, in which case
271 the use of BIND9 is preferred for it's ability to adequately support the SRV (service)
272 records that are needed for Active Directory.
273 </para>
274
275 </sect2>
276
277 <sect2>
278 <title>DNS and Active Directory</title>
279
280 <para>
281 Occasionally we hear from Unix network administrators who want to use a Unix based Dynamic
282 DNS server in place of the Microsoft DNS server. While this might be desirable to some, the
283 MS Windows 200x DNS server is auto-configured to work with Active Directory. It is possible
284 to use BIND version 8 or 9, but it will almost certainly be necessary to create service records
285 so that MS Active Directory clients can resolve host names to locate essential network services.
286 The following are some of the default service records that Active Directory requires:
287 </para>
288
289 <itemizedlist>
290         <listitem><para>_ldap._tcp.pdc.ms-dcs.<emphasis>Domain</emphasis></para>
291
292                 <para>
293                 This provides the address of the Windows NT PDC for the Domain.
294                 </para>
295         </listitem>
296
297         <listitem><para>_ldap._tcp.pdc.ms-dcs.<emphasis>DomainTree</emphasis></para>
298
299                 <para>
300                 Resolves the addresses of Global Catalog servers in the domain.
301                 </para>
302         </listitem>
303
304         <listitem><para>_ldap._tcp.<emphasis>site</emphasis>.sites.writable.ms-dcs.<emphasis>Domain</emphasis></para>
305                 <para>
306                 Provides list of domain controllers based on sites.
307                 </para>
308         </listitem>
309
310         <listitem><para>_ldap._tcp.writable.ms-dcs.<emphasis>Domain</emphasis></para>
311
312                 <para>
313                 Enumerates list of domain controllers that have the writable    
314                 copies of the Active Directory data store.
315                 </para>
316         </listitem>
317
318         <listitem><para>_ldap._tcp.<emphasis>GUID</emphasis>.domains.ms-dcs.<emphasis>DomainTree</emphasis></para>
319                 <para>
320                 Entry used by MS Windows clients to locate machines using the
321                 Global Unique Identifier.
322                 </para>
323         </listitem>
324
325         <listitem><para>_ldap._tcp.<emphasis>Site</emphasis>.gc.ms-dcs.<emphasis>DomainTree</emphasis></para>
326                 <para>
327                 Used by MS Windows clients to locate site configuration dependant
328                 Global Catalog server.
329                 </para>
330         </listitem>
331 </itemizedlist>
332
333 </sect2>
334
335 </sect1>
336
337 <sect1>
338 <title>How Browsing Functions</title>
339
340 <para>
341 MS Windows machines register their NetBIOS names 
342 (ie: the machine name for each service type in operation) on start 
343 up. The exact method by which this name registration 
344 takes place is determined by whether or not the MS Windows client/server 
345 has been given a WINS server address, whether or not LMHOSTS lookup 
346 is enabled, or if DNS for NetBIOS name resolution is enabled, etc.
347 </para>
348
349 <para>
350 In the case where there is no WINS server all name registrations as 
351 well as name lookups are done by UDP broadcast. This isolates name 
352 resolution to the local subnet, unless LMHOSTS is used to list all 
353 names and IP addresses. In such situations Samba provides a means by 
354 which the samba server name may be forcibly injected into the browse 
355 list of a remote MS Windows network (using the 
356 <command>remote announce</command> parameter).
357 </para>
358
359 <para>
360 Where a WINS server is used, the MS Windows client will use UDP 
361 unicast to register with the WINS server. Such packets can be routed 
362 and thus WINS allows name resolution to function across routed networks.
363 </para>
364
365 <para>
366 During the startup process an election will take place to create a 
367 local master browser if one does not already exist. On each NetBIOS network 
368 one machine will be elected to function as the domain master browser. This 
369 domain browsing has nothing to do with MS security domain control. 
370 Instead, the domain master browser serves the role of contacting each local 
371 master browser (found by asking WINS or from LMHOSTS) and exchanging browse 
372 list contents. This way every master browser will eventually obtain a complete 
373 list of all machines that are on the network. Every 11-15 minutes an election 
374 is held to determine which machine will be the master browser. By the nature of 
375 the election criteria used, the machine with the highest uptime, or the 
376 most senior protocol version, or other criteria, will win the election 
377 as domain master browser.
378 </para>
379
380 <para>
381 Clients wishing to browse the network make use of this list, but also depend 
382 on the availability of correct name resolution to the respective IP 
383 address/addresses. 
384 </para>
385
386 <para>
387 Any configuration that breaks name resolution and/or browsing intrinsics 
388 will annoy users because they will have to put up with protracted 
389 inability to use the network services.
390 </para>
391
392 <para>
393 Samba supports a feature that allows forced synchonisation 
394 of browse lists across routed networks using the <command>remote 
395 browse sync</command> parameter in the <filename>smb.conf</filename> file. 
396 This causes Samba to contact the local master browser on a remote network and 
397 to request browse list synchronisation. This effectively bridges 
398 two networks that are separated by routers. The two remote 
399 networks may use either broadcast based name resolution or WINS 
400 based name resolution, but it should be noted that the <command>remote 
401 browse sync</command> parameter provides browse list synchronisation - and 
402 that is distinct from name to address resolution, in other 
403 words, for cross subnet browsing to function correctly it is 
404 essential that a name to address resolution mechanism be provided. 
405 This mechanism could be via DNS, <filename>/etc/hosts</filename>, 
406 and so on.
407 </para>
408
409 <sect2>
410 <title>Setting up WORKGROUP Browsing</title>
411
412 <para>
413 To set up cross subnet browsing on a network containing machines
414 in up to be in a WORKGROUP, not an NT Domain you need to set up one
415 Samba server to be the Domain Master Browser (note that this is *NOT*
416 the same as a Primary Domain Controller, although in an NT Domain the
417 same machine plays both roles).  The role of a Domain master browser is
418 to collate the browse lists from local master browsers on all the
419 subnets that have a machine participating in the workgroup.  Without
420 one machine configured as a domain master browser each subnet would
421 be an isolated workgroup, unable to see any machines on any other
422 subnet.  It is the presense of a domain master browser that makes
423 cross subnet browsing possible for a workgroup.
424 </para>
425
426 <para>
427 In an WORKGROUP environment the domain master browser must be a
428 Samba server, and there must only be one domain master browser per
429 workgroup name.  To set up a Samba server as a domain master browser,
430 set the following option in the <parameter>[global]</parameter> section 
431 of the &smb.conf; file :
432 </para>
433
434 <para>
435 <programlisting>
436         domain master = yes
437 </programlisting>
438 </para>
439
440 <para>
441 The domain master browser should also preferrably be the local master
442 browser for its own subnet.  In order to achieve this set the following
443 options in the <parameter>[global]</parameter> section of the &smb.conf; file :
444 </para>
445
446 <para>
447 <programlisting>
448         domain master = yes
449         local master = yes
450         preferred master = yes
451         os level = 65
452 </programlisting>
453 </para>
454
455 <para>
456 The domain master browser may be the same machine as the WINS
457 server, if you require.
458 </para>
459
460 <para>
461 Next, you should ensure that each of the subnets contains a
462 machine that can act as a local master browser for the
463 workgroup.  Any MS Windows NT/2K/XP/2003  machine should be
464 able to do this, as will Windows 9x machines (although these
465 tend to get rebooted more often, so it's not such a good idea
466 to use these).  To make a Samba server a local master browser
467 set the following options in the <parameter>[global]</parameter> section of the
468 &smb.conf; file :
469 </para>
470
471 <para>
472 <programlisting>
473         domain master = no
474         local master = yes
475         preferred master = yes
476         os level = 65
477 </programlisting>
478 </para>
479
480 <para>
481 Do not do this for more than one Samba server on each subnet,
482 or they will war with each other over which is to be the local
483 master browser.
484 </para>
485
486 <para>
487 The <parameter>local master</parameter> parameter allows Samba to act as a
488 local master browser.  The <parameter>preferred master</parameter> causes nmbd
489 to force a browser election on startup and the <parameter>os level</parameter>
490 parameter sets Samba high enough so that it should win any browser elections.
491 </para>
492
493 <para>
494 If you have an NT machine on the subnet that you wish to
495 be the local master browser then you can disable Samba from
496 becoming a local master browser by setting the following
497 options in the <parameter>[global]</parameter> section of the 
498 &smb.conf; file :
499 </para>
500
501 <para>
502 <programlisting>
503         domain master = no
504         local master = no
505         preferred master = no
506         os level = 0
507 </programlisting>
508 </para>
509
510 </sect2>
511
512 <sect2>
513 <title>Setting up DOMAIN Browsing</title>
514
515 <para>
516 If you are adding Samba servers to a Windows NT Domain then
517 you must not set up a Samba server as a domain master browser.
518 By default, a Windows NT Primary Domain Controller for a Domain
519 name is also the Domain master browser for that name, and many
520 things will break if a Samba server registers the Domain master
521 browser NetBIOS name (<replaceable>DOMAIN</replaceable>&lt;1B&gt;)
522 with WINS instead of the PDC.
523 </para>
524
525 <para>
526 For subnets other than the one containing the Windows NT PDC
527 you may set up Samba servers as local master browsers as
528 described.  To make a Samba server a local master browser set 
529 the following options in the <command>[global]</command> section 
530 of the &smb.conf; file :
531 </para>
532
533 <para>
534 <programlisting>
535         domain master = no
536         local master = yes
537         preferred master = yes
538         os level = 65
539 </programlisting>
540 </para>
541
542 <para>
543 If you wish to have a Samba server fight the election with machines
544 on the same subnet you may set the <parameter>os level</parameter> parameter
545 to lower levels.  By doing this you can tune the order of machines that
546 will become local master browsers if they are running.  For
547 more details on this see the section <link linkend="browse-force-master">
548 Forcing samba to be the master browser</link>
549 below.
550 </para>
551
552 <para>
553 If you have Windows NT machines that are members of the domain
554 on all subnets, and you are sure they will always be running then
555 you can disable Samba from taking part in browser elections and
556 ever becoming a local master browser by setting following options 
557 in the <parameter>[global]</parameter> section of the &smb.conf;
558 file :
559 </para>
560
561 <para>
562 <programlisting>
563         domain master = no
564         local master = no
565         preferred master = no
566         os level = 0
567 </programlisting>
568 </para>
569
570 </sect2>
571
572 <sect2 id="browse-force-master">
573 <title>Forcing samba to be the master</title>
574
575 <para>
576 Who becomes the <parameter>master browser</parameter> is determined by an election
577 process using broadcasts.  Each election packet contains a number of parameters
578 which determine what precedence (bias) a host should have in the
579 election.  By default Samba uses a very low precedence and thus loses
580 elections to just about anyone else.
581 </para>
582
583 <para>
584 If you want Samba to win elections then just set the <parameter>os level</parameter> global
585 option in &smb.conf; to a higher number.  It defaults to 0.  Using 34
586 would make it win all elections over every other system (except other
587 samba systems!)
588 </para>
589
590 <para>
591 A <parameter>os level</parameter> of 2 would make it beat WfWg and Win95, but not MS Windows
592 NT/2K Server.  A MS Windows NT/2K Server domain controller uses level 32.
593 </para>
594
595 <para>The maximum os level is 255</para>
596
597 <para>
598 If you want samba to force an election on startup, then set the
599 <parameter>preferred master</parameter> global option in &smb.conf; to <constant>yes</constant>.  Samba will
600 then have a slight advantage over other potential master browsers
601 that are not preferred master browsers.  Use this parameter with
602 care, as if you have two hosts (whether they are windows 95 or NT or
603 samba) on the same local subnet both set with <parameter>preferred master</parameter> to
604 <constant>yes</constant>, then periodically and continually they will force an election
605 in order to become the local master browser.
606 </para>
607
608 <para>
609         If you want samba to be a <parameter>domain master browser</parameter>, then it is
610 recommended that you also set <parameter>preferred master</parameter> to <constant>yes</constant>, because
611 samba will not become a domain master browser for the whole of your
612 LAN or WAN if it is not also a local master browser on its own
613 broadcast isolated subnet.
614 </para>
615
616 <para>
617 It is possible to configure two samba servers to attempt to become
618 the domain master browser for a domain.  The first server that comes
619 up will be the domain master browser.  All other samba servers will
620 attempt to become the domain master browser every 5 minutes.  They
621 will find that another samba server is already the domain master
622 browser and will fail.  This provides automatic redundancy, should
623 the current domain master browser fail.
624 </para>
625
626 </sect2>
627
628 <sect2>
629 <title>Making samba the domain master</title>
630
631 <para>
632 The domain master is responsible for collating the browse lists of
633 multiple subnets so that browsing can occur between subnets.  You can
634 make samba act as the domain master by setting <parameter>domain master = yes</parameter>
635 in &smb.conf;.  By default it will not be a domain master.
636 </para>
637
638 <para>
639 Note that you should <strong>not</strong> set Samba to be the domain master for a
640 workgroup that has the same name as an NT Domain.
641 </para>
642
643 <para>
644 When samba is the domain master and the master browser it will listen
645 for master announcements (made roughly every twelve minutes) from local
646 master browsers on other subnets and then contact them to synchronise
647 browse lists.
648 </para>
649
650 <para>
651 If you want samba to be the domain master then I suggest you also set
652 the <parameter>os level</parameter> high enough to make sure it wins elections, and set
653 <parameter>preferred master</parameter> to <constant>yes</constant>, to get samba to force an election on
654 startup.
655 </para>
656
657 <para>
658 Note that all your servers (including samba) and clients should be
659 using a WINS server to resolve NetBIOS names.  If your clients are only
660 using broadcasting to resolve NetBIOS names, then two things will occur:
661 </para>
662
663 <orderedlist>
664 <listitem>
665         <para>
666         your local master browsers will be unable to find a domain master
667         browser, as it will only be looking on the local subnet.
668         </para>
669 </listitem>
670
671 <listitem>
672         <para>
673         if a client happens to get hold of a domain-wide browse list, and
674         a user attempts to access a host in that list, it will be unable to
675         resolve the NetBIOS name of that host.
676         </para>
677 </listitem>
678 </orderedlist>
679
680 <para>
681 If, however, both samba and your clients are using a WINS server, then:
682 </para>
683
684 <orderedlist>
685 <listitem>
686         <para>
687         your local master browsers will contact the WINS server and, as long as
688         samba has registered that it is a domain master browser with the WINS
689         server, your local master browser will receive samba's ip address
690         as its domain master browser.
691         </para>
692 </listitem>
693
694 <listitem>
695         <para>
696         when a client receives a domain-wide browse list, and a user attempts
697         to access a host in that list, it will contact the WINS server to
698         resolve the NetBIOS name of that host.  as long as that host has
699         registered its NetBIOS name with the same WINS server, the user will
700         be able to see that host.  
701         </para>
702 </listitem>
703 </orderedlist>
704
705 </sect2>
706
707 <sect2>
708 <title>Note about broadcast addresses</title>
709
710 <para>
711 If your network uses a "0" based broadcast address (for example if it
712 ends in a 0) then you will strike problems.  Windows for Workgroups
713 does not seem to support a 0's broadcast and you will probably find
714 that browsing and name lookups won't work.
715 </para>
716 </sect2>
717
718 <sect2>
719 <title>Multiple interfaces</title>
720
721 <para>
722 Samba now supports machines with multiple network interfaces.  If you
723 have multiple interfaces then you will need to use the <command>interfaces</command>
724 option in &smb.conf; to configure them. 
725 </para>
726 </sect2>
727 <sect2>
728 <title>Use of the Remote Announce parameter</title>
729 <para>
730 The <parameter>remote announce</parameter> parameter of 
731 <filename>smb.conf</filename> can be used to forcibly ensure
732 that all the NetBIOS names on a network get announced to a remote network.
733 The syntax of the <parameter>remote announce</parameter> parameter is:
734 <programlisting>
735         remote announce = a.b.c.d [e.f.g.h] ...
736 </programlisting>
737 _or_
738 <programlisting>
739         remote announce = a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP] ...
740 </programlisting>
741
742 where:
743 <variablelist>
744 <varlistentry><term><replaceable>a.b.c.d</replaceable> and 
745 <replaceable>e.f.g.h</replaceable></term>
746 <listitem><para>is either the LMB (Local Master Browser) IP address
747 or the broadcst address of the remote network.
748 ie: the LMB is at 192.168.1.10, or the address
749 could be given as 192.168.1.255 where the netmask
750 is assumed to be 24 bits (255.255.255.0).
751 When the remote announcement is made to the broadcast
752 address of the remote network every host will receive
753 our announcements. This is noisy and therefore
754 undesirable but may be necessary if we do NOT know
755 the IP address of the remote LMB.</para></listitem>
756 </varlistentry>
757
758 <varlistentry>
759 <term><replaceable>WORKGROUP</replaceable></term>
760 <listitem><para>is optional and can be either our own workgroup
761 or that of the remote network. If you use the
762 workgroup name of the remote network then our
763 NetBIOS machine names will end up looking like
764 they belong to that workgroup, this may cause
765 name resolution problems and should be avoided.
766 </para></listitem>
767 </varlistentry>
768 </variablelist>
769 </para>
770
771 </sect2>
772
773 <sect2>
774 <title>Use of the Remote Browse Sync parameter</title>
775
776 <para>
777 The <parameter>remote browse sync</parameter> parameter of 
778 <filename>smb.conf</filename> is used to announce to
779 another LMB that it must synchronise it's NetBIOS name list with our
780 Samba LMB. It works ONLY if the Samba server that has this option is
781 simultaneously the LMB on it's network segment.
782 </para>
783
784 <para>
785 The syntax of the <parameter>remote browse sync</parameter> parameter is:
786
787 <programlisting>
788 remote browse sync = <replaceable>a.b.c.d</replaceable>
789 </programlisting>
790
791 where <replaceable>a.b.c.d</replaceable> is either the IP address of the
792 remote LMB or else is the network broadcast address of the remote segment.
793 </para>
794
795 </sect2>
796
797 </sect1>
798
799 <sect1>
800 <title>WINS - The Windows Internetworking Name Server</title>
801
802 <para>
803 Use of WINS (either Samba WINS _or_ MS Windows NT Server WINS) is highly
804 recommended. Every NetBIOS machine registers it's name together with a
805 name_type value for each of of several types of service it has available.
806 eg: It registers it's name directly as a unique (the type 0x03) name.
807 It also registers it's name if it is running the lanmanager compatible
808 server service (used to make shares and printers available to other users)
809 by registering the server (the type 0x20) name.
810 </para>
811
812 <para>
813 All NetBIOS names are up to 15 characters in length. The name_type variable
814 is added to the end of the name - thus creating a 16 character name. Any
815 name that is shorter than 15 characters is padded with spaces to the 15th
816 character. ie: All NetBIOS names are 16 characters long (including the
817 name_type information).
818 </para>
819
820 <para>
821 WINS can store these 16 character names as they get registered. A client
822 that wants to log onto the network can ask the WINS server for a list
823 of all names that have registered the NetLogon service name_type. This saves
824 broadcast traffic and greatly expedites logon processing. Since broadcast
825 name resolution can not be used across network segments this type of
826 information can only be provided via WINS _or_ via statically configured
827 <filename>lmhosts</filename> files that must reside on all clients in the
828 absence of WINS.
829 </para>
830
831 <para>
832 WINS also serves the purpose of forcing browse list synchronisation by all
833 LMB's. LMB's must synchronise their browse list with the DMB (domain master
834 browser) and WINS helps the LMB to identify it's DMB. By definition this
835 will work only within a single workgroup. Note that the domain master browser
836 has NOTHING to do with what is referred to as an MS Windows NT Domain. The
837 later is a reference to a security environment while the DMB refers to the
838 master controller for browse list information only.
839 </para>
840
841 <para>
842 Use of WINS will work correctly only if EVERY client TCP/IP protocol stack
843 has been configured to use the WINS server/s. Any client that has not been
844 configured to use the WINS server will continue to use only broadcast based
845 name registration so that WINS may NEVER get to know about it. In any case,
846 machines that have not registered with a WINS server will fail name to address
847 lookup attempts by other clients and will therefore cause workstation access
848 errors.
849 </para>
850
851 <para>
852 To configure Samba as a WINS server just add 
853 <parameter>wins support = yes</parameter> to the <filename>smb.conf</filename>
854 file [globals] section.
855 </para>
856
857 <para>
858 To configure Samba to register with a WINS server just add
859 <parameter>wins server = a.b.c.d</parameter> to your &smb.conf; file <parameter>[globals]</parameter> section.
860 </para>
861
862 <important><para>
863 Never use both <parameter>wins support = yes</parameter> together
864 with <parameter>wins server = a.b.c.d</parameter>
865 particularly not using it's own IP address.
866 Specifying both will cause &nmbd; to refuse to start!
867 </para></important>
868
869 <sect2>
870 <title>Setting up a WINS server</title>
871
872 <para>
873 Either a Samba machine or a Windows NT Server machine may be set up
874 as a WINS server.  To set a Samba machine to be a WINS server you must
875 add the following option to the &smb.conf; file on the selected machine :
876 in the <parameter>[globals]</parameter> section add the line 
877 </para>
878
879 <para>
880 <programlisting>
881         wins support = yes
882 </programlisting>
883 </para>
884
885 <para>
886 Versions of Samba prior to 1.9.17 had this parameter default to
887 yes.  If you have any older versions of Samba on your network it is
888 strongly suggested you upgrade to a recent version, or at the very
889 least set the parameter to 'no' on all these machines.
890 </para>
891
892 <para>
893 Machines with <parameter>wins support = yes</parameter> will keep a list of 
894 all NetBIOS names registered with them, acting as a DNS for NetBIOS names.
895 </para>
896
897 <para>
898 You should set up only ONE wins server.  Do NOT set the
899 <parameter>wins support = yes</parameter> option on more than one Samba 
900 server.
901 </para>
902
903 <para>
904 To set up a Windows NT Server as a WINS server you need to set up
905 the WINS service - see your NT documentation for details.  Note that
906 Windows NT WINS Servers can replicate to each other, allowing more
907 than one to be set up in a complex subnet environment.  As Microsoft
908 refuse to document these replication protocols Samba cannot currently
909 participate in these replications.  It is possible in the future that
910 a Samba->Samba WINS replication protocol may be defined, in which
911 case more than one Samba machine could be set up as a WINS server
912 but currently only one Samba server should have the 
913 <parameter>wins support = yes</parameter> parameter set.
914 </para>
915
916 <para>
917 After the WINS server has been configured you must ensure that all
918 machines participating on the network are configured with the address
919 of this WINS server.  If your WINS server is a Samba machine, fill in
920 the Samba machine IP address in the <guilabel>Primary WINS Server</guilabel> field of
921 the <guilabel>Control Panel->Network->Protocols->TCP->WINS Server</guilabel> dialogs
922 in Windows 95 or Windows NT.  To tell a Samba server the IP address
923 of the WINS server add the following line to the <parameter>[global]</parameter> section of
924 all &smb.conf; files :
925 </para>
926
927 <para>
928 <programlisting>
929         wins server = &lt;name or IP address&gt;
930 </programlisting>
931 </para>
932
933 <para>
934 where &lt;name or IP address&gt; is either the DNS name of the WINS server
935 machine or its IP address.
936 </para>
937
938 <para>
939 Note that this line MUST NOT BE SET in the &smb.conf; file of the Samba
940 server acting as the WINS server itself.  If you set both the
941 <parameter>wins support = yes</parameter> option and the 
942 <parameter>wins server = &lt;name&gt;</parameter> option then
943 nmbd will fail to start.
944 </para>
945
946 <para>
947 There are two possible scenarios for setting up cross subnet browsing.
948 The first details setting up cross subnet browsing on a network containing
949 Windows 95, Samba and Windows NT machines that are not configured as
950 part of a Windows NT Domain.  The second details setting up cross subnet
951 browsing on networks that contain NT Domains.
952 </para>
953
954 </sect2>
955
956 <sect2>
957 <title>WINS Replication</title>
958
959 <para>
960 Samba-3 permits WINS replication through the use of the <filename>wrepld</filename> utility.
961 This tool is not currently capable of being used as it is still in active development.
962 As soon as this tool becomes moderately functional we will prepare man pages and enhance this
963 section of the documentation to provide usage and technical details.
964 </para>
965
966 </sect2>
967 <sect2>
968 <title>Static WINS Entries</title>
969
970 <para>
971 New to Samba-3 is a tool called <command>winsedit</command> that may be used to add
972 static WINS entries to the WINS database. This tool can be used also to modify entries
973 existing in the WINS database.
974 </para>
975
976 <para>
977 The development of the winsedit tool was made necessary due to the migration
978 of the older style wins.dat file into a new tdb binary backend data store.
979 </para>
980
981 </sect2>
982 </sect1>
983
984 <sect1>
985 <title>Helpful Hints</title>
986
987 <para>
988 The following hints should be carefully considered as they are stumbling points
989 for many new network administrators.
990 </para>
991
992 <sect2>
993 <title>Windows Networking Protocols</title>
994
995 <warning><para>
996 Do NOT use more than one (1) protocol on MS Windows machines
997 </para></warning>
998
999 <para>
1000 A very common cause of browsing problems results from installing more than
1001 one protocol on an MS Windows machine.
1002 </para>
1003
1004 <para>
1005 Every NetBIOS machine takes part in a process of electing the LMB (and DMB)
1006 every 15 minutes. A set of election criteria is used to determine the order
1007 of precidence for winning this election process. A machine running Samba or
1008 Windows NT will be biased so that the most suitable machine will predictably
1009 win and thus retain it's role.
1010 </para>
1011
1012 <para>
1013 The election process is "fought out" so to speak over every NetBIOS network
1014 interface. In the case of a Windows 9x machine that has both TCP/IP and IPX
1015 installed and has NetBIOS enabled over both protocols the election will be
1016 decided over both protocols. As often happens, if the Windows 9x machine is
1017 the only one with both protocols then the LMB may be won on the NetBIOS
1018 interface over the IPX protocol. Samba will then lose the LMB role as Windows
1019 9x will insist it knows who the LMB is. Samba will then cease to function
1020 as an LMB and thus browse list operation on all TCP/IP only machines will
1021 fail.
1022 </para>
1023
1024 <para><emphasis>
1025 Windows 95, 98, 98se, Me are referred to generically as Windows 9x.
1026 The Windows NT4, 2000, XP and 2003 use common protocols. These are roughly
1027 referred to as the WinNT family, but it should be recognised that 2000 and
1028 XP/2003 introduce new protocol extensions that cause them to behave 
1029 differently from MS Windows NT4. Generally, where a server does NOT support
1030 the newer or extended protocol, these will fall back to the NT4 protocols.
1031 </emphasis></para>
1032
1033 <para>
1034 The safest rule of all to follow it this - USE ONLY ONE PROTOCOL!
1035 </para>
1036
1037 </sect2>
1038
1039 <sect2>
1040 <title>Name Resolution Order</title>
1041
1042 <para>
1043 Resolution of NetBIOS names to IP addresses can take place using a number
1044 of methods. The only ones that can provide NetBIOS name_type information
1045 are:</para>
1046
1047 <simplelist>
1048         <member>WINS: the best tool!</member>
1049         <member>LMHOSTS: is static and hard to maintain.</member>
1050         <member>Broadcast: uses UDP and can not resolve names across remote segments.</member>
1051 </simplelist>
1052
1053 <para>
1054 Alternative means of name resolution includes:</para>
1055 <simplelist>
1056 <member><filename>/etc/hosts</filename>: is static, hard to maintain, and lacks name_type info</member>
1057 <member>DNS: is a good choice but lacks essential name_type info.</member>
1058 </simplelist>
1059
1060 <para>
1061 Many sites want to restrict DNS lookups and want to avoid broadcast name
1062 resolution traffic. The "name resolve order" parameter is of great help here.
1063 The syntax of the "name resolve order" parameter is:
1064 <programlisting>
1065 name resolve order = wins lmhosts bcast host
1066 </programlisting>
1067 _or_
1068 <programlisting>
1069 name resolve order = wins lmhosts       (eliminates bcast and host)
1070 </programlisting>
1071 The default is:
1072 <programlisting>
1073 name  resolve order = host lmhost wins bcast
1074 </programlisting>
1075 where "host" refers the the native methods used by the Unix system
1076 to implement the gethostbyname() function call. This is normally
1077 controlled by <filename>/etc/host.conf</filename>, <filename>/etc/nsswitch.conf</filename> and <filename>/etc/resolv.conf</filename>.
1078 </para>
1079 </sect2>
1080 </sect1>
1081
1082 <sect1>
1083 <title>Technical Overview of browsing</title>
1084
1085 <para>
1086 SMB networking provides a mechanism by which clients can access a list
1087 of machines in a network, a so-called <parameter>browse list</parameter>.  This list
1088 contains machines that are ready to offer file and/or print services
1089 to other machines within the network. Thus it does not include
1090 machines which aren't currently able to do server tasks.  The browse
1091 list is heavily used by all SMB clients.  Configuration of SMB
1092 browsing has been problematic for some Samba users, hence this
1093 document.
1094 </para>
1095
1096 <para>
1097 MS Windows 2000 and later, as with Samba 3 and later, can be
1098 configured to not use NetBIOS over TCP/IP. When configured this way
1099 it is imperative that name resolution (using DNS/LDAP/ADS) be correctly
1100 configured and operative. Browsing will NOT work if name resolution
1101 from SMB machine names to IP addresses does not function correctly.
1102 </para>
1103
1104 <para>
1105 Where NetBIOS over TCP/IP is enabled use of a WINS server is highly
1106 recommended to aid the resolution of NetBIOS (SMB) names to IP addresses.
1107 WINS allows remote segment clients to obtain NetBIOS name_type information
1108 that can NOT be provided by any other means of name resolution.
1109 </para>
1110
1111 <sect2>
1112 <title>Browsing support in samba</title>
1113
1114 <para>
1115 Samba facilitates browsing.  The browsing is supported by &nmbd;
1116 and is also controlled by options in the &smb.conf; file.
1117 Samba can act as a local browse master for a workgroup and the ability
1118 to support domain logons and scripts is now available.
1119 </para>
1120
1121 <para>
1122 Samba can also act as a domain master browser for a workgroup.  This
1123 means that it will collate lists from local browse masters into a
1124 wide area network server list.  In order for browse clients to
1125 resolve the names they may find in this list, it is recommended that
1126 both samba and your clients use a WINS server.
1127 </para>
1128
1129 <para>
1130 Note that you should NOT set Samba to be the domain master for a
1131 workgroup that has the same name as an NT Domain: on each wide area
1132 network, you must only ever have one domain master browser per workgroup,
1133 regardless of whether it is NT, Samba or any other type of domain master
1134 that is providing this service.
1135 </para>
1136
1137 <note><para>
1138 Nmbd can be configured as a WINS server, but it is not
1139 necessary to specifically use samba as your WINS server.  MS Windows
1140 NT4, Server or Advanced Server 2000 or 2003 can be configured as
1141 your WINS server.  In a mixed NT/2000/2003 server and samba environment on
1142 a Wide Area Network, it is recommended that you use the Microsoft
1143 WINS server capabilities.  In a samba-only environment, it is
1144 recommended that you use one and only one Samba server as your WINS server.
1145 </para></note>
1146
1147 <para>
1148 To get browsing to work you need to run nmbd as usual, but will need
1149 to use the <parameter>workgroup</parameter> option in &smb.conf;
1150 to control what workgroup Samba becomes a part of.
1151 </para>
1152
1153 <para>
1154 Samba also has a useful option for a Samba server to offer itself for
1155 browsing on another subnet.  It is recommended that this option is only
1156 used for 'unusual' purposes: announcements over the internet, for
1157 example.  See <parameter>remote announce</parameter> in the 
1158 &smb.conf; man page.  
1159 </para>
1160 </sect2>
1161
1162 <sect2>
1163 <title>Problem resolution</title>
1164
1165 <para>
1166 If something doesn't work then hopefully the log.nmb file will help
1167 you track down the problem.  Try a debug level of 2 or 3 for finding
1168 problems. Also note that the current browse list usually gets stored
1169 in text form in a file called <filename>browse.dat</filename>.
1170 </para>
1171
1172 <para>
1173 Note that if it doesn't work for you, then you should still be able to
1174 type the server name as <filename>\\SERVER</filename> in filemanager then
1175 hit enter and filemanager should display the list of available shares.
1176 </para>
1177
1178 <para>
1179 Some people find browsing fails because they don't have the global
1180 <parameter>guest account</parameter> set to a valid account.  Remember that the
1181 IPC$ connection that lists the shares is done as guest, and thus you must
1182 have a valid guest account.
1183 </para>
1184
1185 <para><emphasis>
1186 MS Windows 2000 and upwards (as with Samba) can be configured to disallow
1187 anonymous (ie: Guest account) access to the IPC$ share. In that case, the
1188 MS Windows 2000/XP/2003 machine acting as an SMB/CIFS client will use the
1189 name of the currently logged in user to query the IPC$ share. MS Windows
1190 9X clients are not able to do this and thus will NOT be able to browse
1191 server resources.
1192 </emphasis></para>
1193
1194 <para>
1195 The other big problem people have is that their broadcast address,
1196 netmask or IP address is wrong (specified with the "interfaces" option
1197 in &smb.conf;)
1198 </para>
1199 </sect2>
1200
1201 <sect2>
1202 <title>Browsing across subnets</title>
1203 <para>
1204 Since the release of Samba 1.9.17(alpha1) Samba has been
1205 updated to enable it to support the replication of browse lists
1206 across subnet boundaries.  New code and options have been added to
1207 achieve this.  This section describes how to set this feature up
1208 in different settings.
1209 </para>
1210
1211 <para>
1212 To see browse lists that span TCP/IP subnets (ie.  networks separated
1213 by routers that don't pass broadcast traffic) you must set up at least
1214 one WINS server.  The WINS server acts as a DNS for NetBIOS names, allowing
1215 NetBIOS name to IP address translation to be done by doing a direct
1216 query of the WINS server.  This is done via a directed UDP packet on
1217 port 137 to the WINS server machine.  The reason for a WINS server is
1218 that by default, all NetBIOS name to IP address translation is done
1219 by broadcasts from the querying machine.  This means that machines
1220 on one subnet will not be able to resolve the names of machines on
1221 another subnet without using a WINS server.
1222 </para>
1223
1224 <para>
1225 Remember, for browsing across subnets to work correctly, all machines,
1226 be they Windows 95, Windows NT, or Samba servers must have the IP address
1227 of a WINS server given to them by a DHCP server, or by manual configuration 
1228 (for Win95 and WinNT, this is in the TCP/IP Properties, under Network 
1229 settings) for Samba this is in the &smb.conf; file.
1230 </para>
1231
1232 <sect3>
1233 <title>How does cross subnet browsing work ?</title>
1234
1235 <para>
1236 Cross subnet browsing is a complicated dance, containing multiple
1237 moving parts.  It has taken Microsoft several years to get the code
1238 that achieves this correct, and Samba lags behind in some areas.
1239 Samba is capable of cross subnet browsing when configured correctly.
1240 </para>
1241
1242 <para>
1243 Consider a network set up as follows :
1244 </para>
1245
1246 <para>
1247         <!-- FIXME: Convert this to diagram -->
1248 <programlisting>
1249                                    (DMB)
1250              N1_A      N1_B        N1_C       N1_D        N1_E
1251               |          |           |          |           |
1252           -------------------------------------------------------
1253             |          subnet 1                       |
1254           +---+                                      +---+
1255           |R1 | Router 1                  Router 2   |R2 |
1256           +---+                                      +---+
1257             |                                          |
1258             |  subnet 2              subnet 3          |
1259   --------------------------       ------------------------------------
1260   |     |     |      |               |        |         |           |
1261  N2_A  N2_B  N2_C   N2_D           N3_A     N3_B      N3_C        N3_D 
1262                     (WINS)
1263 </programlisting>
1264 </para>
1265         
1266 <para>
1267 Consisting of 3 subnets (1, 2, 3) connected by two routers
1268 (R1, R2) - these do not pass broadcasts.  Subnet 1 has 5 machines
1269 on it, subnet 2 has 4 machines, subnet 3 has 4 machines.  Assume
1270 for the moment that all these machines are configured to be in the
1271 same workgroup (for simplicities sake).  Machine N1_C on subnet 1
1272 is configured as Domain Master Browser (ie.  it will collate the
1273 browse lists for the workgroup).  Machine N2_D is configured as
1274 WINS server and all the other machines are configured to register
1275 their NetBIOS names with it.
1276 </para>
1277
1278 <para>
1279 As all these machines are booted up, elections for master browsers
1280 will take place on each of the three subnets.  Assume that machine
1281 N1_C wins on subnet 1, N2_B wins on subnet 2, and N3_D wins on
1282 subnet 3 - these machines are known as local master browsers for
1283 their particular subnet.  N1_C has an advantage in winning as the
1284 local master browser on subnet 1 as it is set up as Domain Master
1285 Browser.
1286 </para>
1287
1288 <para>
1289 On each of the three networks, machines that are configured to 
1290 offer sharing services will broadcast that they are offering
1291 these services.  The local master browser on each subnet will
1292 receive these broadcasts and keep a record of the fact that
1293 the machine is offering a service.  This list of records is
1294 the basis of the browse list.  For this case, assume that
1295 all the machines are configured to offer services so all machines
1296 will be on the browse list.
1297 </para>
1298
1299 <para>
1300 For each network, the local master browser on that network is
1301 considered 'authoritative' for all the names it receives via
1302 local broadcast.  This is because a machine seen by the local
1303 master browser via a local broadcast must be on the same 
1304 network as the local master browser and thus is a 'trusted'
1305 and 'verifiable' resource.  Machines on other networks that
1306 the local master browsers learn about when collating their
1307 browse lists have not been directly seen - these records are
1308 called 'non-authoritative'.
1309 </para>
1310
1311 <para>
1312 At this point the browse lists look as follows (these are 
1313 the machines you would see in your network neighborhood if
1314 you looked in it on a particular network right now).
1315 </para>
1316
1317 <para>
1318 <table>
1319         <tgroup align="left" cols="3">
1320         <thead>
1321                 <row><entry>Subnet</entry><entry>Browse Master</entry><entry>List</entry></row>
1322         </thead>
1323
1324         <tbody>
1325                 <row><entry>Subnet1</entry><entry>N1_C</entry><entry>N1_A, N1_B, N1_C, N1_D, N1_E</entry></row>
1326                 <row><entry>Subnet2</entry><entry>N2_B</entry><entry>N2_A, N2_B, N2_C, N2_D</entry></row>
1327                 <row><entry>Subnet3</entry><entry>N3_D</entry><entry>N3_A, N3_B, N3_C, N3_D</entry></row>
1328         </tbody>
1329         </tgroup>
1330 </table>
1331 </para>
1332
1333 <para>
1334 Note that at this point all the subnets are separate, no
1335 machine is seen across any of the subnets.
1336 </para>
1337
1338 <para>
1339 Now examine subnet 2.  As soon as N2_B has become the local
1340 master browser it looks for a Domain master browser to synchronize
1341 its browse list with.  It does this by querying the WINS server
1342 (N2_D) for the IP address associated with the NetBIOS name 
1343 WORKGROUP&lt;1B&gt;.  This name was registerd by the Domain master
1344 browser (N1_C) with the WINS server as soon as it was booted.
1345 </para>
1346
1347 <para>
1348 Once N2_B knows the address of the Domain master browser it
1349 tells it that is the local master browser for subnet 2 by
1350 sending a MasterAnnouncement packet as a UDP port 138 packet.
1351 It then synchronizes with it by doing a NetServerEnum2 call.  This
1352 tells the Domain Master Browser to send it all the server
1353 names it knows about.  Once the domain master browser receives
1354 the MasterAnnouncement packet it schedules a synchronization
1355 request to the sender of that packet.  After both synchronizations
1356 are done the browse lists look like :
1357 </para>
1358
1359 <para>
1360 <table>
1361         <tgroup align="left" cols="3">
1362         <thead>
1363                 <row><entry>Subnet</entry><entry>Browse Master</entry><entry>List</entry></row>
1364         </thead>
1365
1366         <tbody>
1367                 <row><entry>Subnet1</entry><entry>N1_C</entry><entry>N1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*)</entry></row>
1368                 <row><entry>Subnet2</entry><entry>N2_B</entry><entry>N2_A, N2_B, N2_C, N2_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)</entry></row>
1369                 <row><entry>Subnet3</entry><entry>N3_D</entry><entry>N3_A, N3_B, N3_C, N3_D</entry></row>
1370         </tbody>
1371         </tgroup>
1372 </table>
1373
1374 Servers with a (*) after them are non-authoritative names.
1375 </para>
1376
1377 <para>
1378 At this point users looking in their network neighborhood on
1379 subnets 1 or 2 will see all the servers on both, users on
1380 subnet 3 will still only see the servers on their own subnet.
1381 </para>
1382
1383 <para>
1384 The same sequence of events that occured for N2_B now occurs
1385 for the local master browser on subnet 3 (N3_D).  When it
1386 synchronizes browse lists with the domain master browser (N1_A)
1387 it gets both the server entries on subnet 1, and those on
1388 subnet 2.  After N3_D has synchronized with N1_C and vica-versa
1389 the browse lists look like.
1390 </para>
1391
1392 <para>
1393 <table>
1394         <tgroup cols="3" align="left">
1395         <thead>
1396                 <row><entry>Subnet</entry><entry>Browse Master</entry><entry>List</entry></row>
1397         </thead>
1398
1399         <tbody>
1400                 <row><entry>Subnet1</entry><entry>N1_C</entry><entry>N1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*)</entry></row>
1401                 <row><entry>Subnet2</entry><entry>N2_B</entry><entry>N2_A, N2_B, N2_C, N2_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)</entry></row>
1402                 <row><entry>Subnet3</entry><entry>N3_D</entry><entry>N3_A, N3_B, N3_C, N3_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), N2_A(*), N2_B(*), N2_C(*), N2_D(*)</entry></row>
1403         </tbody>
1404         </tgroup>
1405 </table>
1406
1407 Servers with a (*) after them are non-authoritative names.
1408 </para>
1409
1410 <para>
1411 At this point users looking in their network neighborhood on
1412 subnets 1 or 3 will see all the servers on all sunbets, users on
1413 subnet 2 will still only see the servers on subnets 1 and 2, but not 3.
1414 </para>
1415
1416 <para>
1417 Finally, the local master browser for subnet 2 (N2_B) will sync again
1418 with the domain master browser (N1_C) and will recieve the missing
1419 server entries.  Finally - and as a steady state (if no machines
1420 are removed or shut off) the browse lists will look like :
1421 </para>
1422
1423 <para>
1424 <table>
1425         <tgroup cols="3" align="left">
1426         <thead>
1427                 <row><entry>Subnet</entry><entry>Browse Master</entry><entry>List</entry></row>
1428         </thead>
1429
1430         <tbody>
1431                 <row><entry>Subnet1</entry><entry>N1_C</entry><entry>N1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*)</entry></row>
1432                 <row><entry>Subnet2</entry><entry>N2_B</entry><entry>N2_A, N2_B, N2_C, N2_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*)</entry></row>
1433                 <row><entry>Subnet3</entry><entry>N3_D</entry><entry>N3_A, N3_B, N3_C, N3_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), N2_A(*), N2_B(*), N2_C(*), N2_D(*)</entry></row>
1434         </tbody>
1435         </tgroup>
1436 </table>
1437         
1438 Servers with a (*) after them are non-authoritative names.
1439 </para>
1440
1441 <para>
1442 Synchronizations between the domain master browser and local
1443 master browsers will continue to occur, but this should be a
1444 steady state situation.
1445 </para>
1446
1447 <para>
1448 If either router R1 or R2 fails the following will occur:
1449 </para>
1450
1451 <orderedlist>
1452 <listitem>
1453         <para>
1454         Names of computers on each side of the inaccessible network fragments
1455         will be maintained for as long as 36 minutes, in the network neighbourhood
1456         lists.
1457         </para>
1458 </listitem>
1459
1460 <listitem>
1461         <para>
1462         Attempts to connect to these inaccessible computers will fail, but the
1463         names will not be removed from the network neighbourhood lists.
1464         </para>
1465 </listitem>
1466
1467 <listitem>
1468         <para>
1469         If one of the fragments is cut off from the WINS server, it will only
1470         be able to access servers on its local subnet, by using subnet-isolated
1471         broadcast NetBIOS name resolution.  The effects are similar to that of
1472         losing access to a DNS server.
1473         </para>
1474 </listitem>
1475 </orderedlist>
1476 </sect3>
1477 </sect2>
1478 </sect1>
1479
1480 <sect1>
1481 <title>Common Errors</title>
1482
1483 <para>
1484 Many questions are sked on the mailing lists regarding browsing. The majority of browsing
1485 problems originate out of incorrect configuration of NetBIOS name resolution. Some are of
1486 particular note.
1487 </para>
1488
1489 <sect2>
1490 <title>How can one flush the Samba NetBIOS name cache without restarting samba?</title>
1491
1492 <para>
1493 Sambas' nmbd process controls all browse list handling. Under normal circumstances it is
1494 safe to restart nmbd. This will effectively flush the samba NetBIOS name cache and cause it
1495 to be rebuilt. Note that this does NOT make certain that a rogue machine name will not re-appear
1496 in the browse list. When nmbd is taken out of service another machine on the network will
1497 become the browse master. This new list may still have the rogue entry in it. If you really
1498 want to clear a rogue machine from the list then every machine on the network will need to be
1499 shut down and restarted at after all machines are down. Failing a complete restart, the only
1500 other thing you can do is wait until the entry times out and is then flushed from the list.
1501 This may take a long time on some networks (months).
1502 </para>
1503
1504 </sect2>
1505 </sect1>
1506 </chapter>