WINS - Revision history

118.209.52.85: Removed Chatter

2012-08-09T04:33:52Z

Removed Chatter

Jimbo: revert spam

2011-08-01T22:24:00Z

revert spam

Jimbo: Reverted edits by 210.88.61.50 (Talk) to last revision by 41.133.87.50

2011-08-01T22:22:11Z

Reverted edits by 210.88.61.50 (Talk) to last revision by 41.133.87.50

210.88.61.50: /* Related Systems */

2011-05-12T04:17:44Z

Related Systems

41.133.87.50: /* DHCP */

2011-05-10T17:09:04Z

DHCP

217.169.176.180: /* Notes */

2011-05-09T03:27:38Z

Notes

174.129.93.87: /* Features */

2011-05-08T20:25:39Z

Features

Jimbo: /* Notes */

2008-08-20T13:44:20Z

Notes

Jimbo: /* DHCP */

2008-08-20T13:43:07Z

DHCP

Jimbo: /* Samba */

2008-08-20T13:42:29Z

Samba

@@ Line 12: / Line 12: @@
 It soon became apparent that a service was required that would reduce the network load while making hostname resolution more efficient and quicker.  This is where NBNS, and later WINS, came into existence.
 == Related Systems ==
@@ Line 28: / Line 26: @@
 The other side of WINS is that it tracks hostnames to the IP addresses of hosts on the network that have themselves been given a dynamically allocated IP address from DHCP.
 == See Also ==

@@ Line 23: / Line 23: @@
 The WINS service on Unixlike OSes is implemented through Samba. WINS is primarily intended for use on networks that contain many SMB (Windows) network hosts, where an ability to resolve their hostnames without resorting to broadcasting will improve network performance and efficiency.
-AFAIC that's the best aswner so far!
+=== DHCP ===
 == See Also ==

@@ Line 15: / Line 15: @@
 What a joy to find someone else who tikhns this way.
-Fnok0q  <a href="http://vasmjaszfnqn.com/">vasmjaszfnqn</a>
+== Related Systems ==
 == See Also ==

@@ Line 15: / Line 15: @@
 What a joy to find someone else who tikhns this way.
-== Related Systems ==
+Fnok0q  <a href="http://vasmjaszfnqn.com/">vasmjaszfnqn</a>
-−
-The WINS service is very functional on its own but it does rely on other network services with which to make it effective.  The following are based on making the WINS service available using FreeBSD as the host operating system:
-−
-=== Samba ===
-−
-The WINS service on Unixlike OSes is implemented through Samba. WINS is primarily intended for use on networks that contain many SMB (Windows) network hosts, where an ability to resolve their hostnames without resorting to broadcasting will improve network performance and efficiency.
-−
-AFAIC that's the best aswner so far!
 == See Also ==

@@ Line 23: / Line 23: @@
 The WINS service on Unixlike OSes is implemented through Samba. WINS is primarily intended for use on networks that contain many SMB (Windows) network hosts, where an ability to resolve their hostnames without resorting to broadcasting will improve network performance and efficiency.
-=== DHCP ===
+AFAIC that's the best aswner so far!
-−
-The DHCP server is capable of sending details of one or more WINS servers as part of an IP address request or renewal, just as it would with default gateway and DNS details.  The DHCP configuration option #44, called 'WINS/NBNS' on Microsoft platforms or 'NetBIOS Name Service' on other DHCP implementations, holds the IP addresses for the WINS service hosts.
-−
-The other side of WINS is that it tracks hostnames to the IP addresses of hosts on the network that have themselves been given a dynamically allocated IP address from DHCP.
-−
-Sueprior thinking demonstrated above. Thanks!
 == See Also ==

@@ Line 29: / Line 29: @@
 The other side of WINS is that it tracks hostnames to the IP addresses of hosts on the network that have themselves been given a dynamically allocated IP address from DHCP.
-== Notes ==
+Sueprior thinking demonstrated above. Thanks!
-−
-The Microsoft implementation of the WINS service required a Primary Domain Controller, and therefore a full NT-domain to exist, in order to have a domain master browser and, from there, be able to span multiple network subnets using the push/pull replication setup.  The Samba implementation does not have this requirement and can function this way even in workgroup mode.  However, a Samba WINS server cannot replicate with a Microsoft WINS server and vice-versa.  So it is important to only use one implementation across all network subnets in order to avoid inconsistencies between WINS servers.
-−
-When using DHCP to send details of the WINS service servers to Microsoft Windows based hosts it is worth setting option #46, known as the ''WINS/NBT Node Type'' (Microsoft) or ''NetBIOS Node Type'' (others), to a value of '8'.  This value configures the behaviour of the name resolution order on these hosts.  The available options are:
-−
-* 1 - 'bnode', for broadcast only;
-* 2 - 'pnode', for WINS only;
-* 4 - 'mnode', for broadcast first, WINS second;
-* 8 - 'hnode', for WINS first, broadcast second;
-−
-The default behaviour of Microsoft Windows based hosts is to use option '8' when WINS server addresses are specified, either by DHCP or when manually configured on the host, and use option '1' when neither DHCP nor manual configuration specify a WINS server address.
-−
-=== For Microsoft Exchange Administrators ===
-−
-Those using Microsoft Exchange 2000 Server or Exchange Server 2003 in an Active Directory environment may find it worth noting that WINS is required for full functionality due to various dependencies in the Exchange server services.  See this [http://support.microsoft.com/kb/837391 knowledge base] article for further details.
 == See Also ==

@@ Line 13: / Line 13: @@
 It soon became apparent that a service was required that would reduce the network load while making hostname resolution more efficient and quicker.  This is where NBNS, and later WINS, came into existence.
-== Features ==
+What a joy to find someone else who tikhns this way.
-−
-The WINS service works within a network subnet and provides name resolution based on host NetBIOS names and their associated IP address.  It can be thought of as a kind of Dynamic-DNS style service but instead of internet-based hosts it deals with workgroup-based and domain-based hosts.  As such it is tied into the LAN-Manager style network infrastructure, nowadays more commonly referred to as SMB (latterly CIFS) on Microsoft platforms or [[Samba]] on UNIX and Unix-like platforms.  The server operating as the primary WINS service is often referred to as the ''local master browser'' in a workgroup or ''domain master browser'' in an NT-based domain.  It is possible to have multiple WINS service servers on the same network subnet with one being the ''master browser'' and the others being ''backup browser'' servers.
-−
-The service differs from DNS in that it cannot span across networks via routers on IP based networks, therefore it is limited to the network subnet it resides within.  To work around this limitation a push/pull replication setup can be implemented and often utilised in a spoke/hub topological configuration.  Without this arrangement a host on the network subnet can only query the local WINS service and not know about hosts on other subnets.  However with this arrangement a host can determine another host's IP address from another network subnet and then rely on TCP/IP routing to communicate to it which makes it more akin to DNS.
-−
-With DNS it is possible to have the same hostname several times but under different sub-domains.  A typical example would be www.us.domain.net and www.uk.domain.net where the hostname '''www''' exists twice with one under the '''us''' and the other under the '''uk''' sub-domains.  This is possible because DNS is hierarchical in operation.  With WINS there is no hierarchical system and as such duplicate hostnames cannot exist, especially across different network subnets, when the push/pull system is used.  This is not necessarily a limitation of WINS since a flat domain model would not permit more then one hostname to be used, and WINS is intended to be used on corporate networks as part of file and print sharing where server names are unique.
 == Related Systems ==