Useful Links:
WINS at Yale
This is intended as a (relatively) non-technical discussion of how WSS recommends that WINS be configured on servers and clients for maximum visibility of services.
The main idea of this plan is that while it's tempting to simply oint thousands of clients at a single WINS server (or group of servers), it's unnecessary to aim for 100% WINS coverage for all systems (so that every machine can see every other machine no matter where the two are) but instead to make sure that people have 100% WINS coverage for the machines that they will be interacting with.
The difference is VERY significant.
What is WINS?
WINS, an acronym for "Windows Internet Name Service" is Microsoft's implementation of a loosely-defined "NetBIOS name server" that is described in RFC's 1001 and 1002. These RFC's describe a service that maps NetBIOS names for to IP addresses along with a notation that indicates what function that name is associated with.
The WINS server maintains a table of machine names, type codes and IP numbers and responds to queries against that table by client systems. This table is maintained by the Microsoft "jet" database engine. Jet and WINS were notoriously buggy in their first several versions of NT, with a nasty tendency to corrupt the name tables and render the WINS server useless. Because of that, many NT admins swore off using WINS forever at an early stage in their NT experience.
Fortunately, these bugs were worked out in the last couple of service packs for NT 4 and in Windows 2000 and it now seems to work fine, though heavy replication traffic sometimes still seems to cause problems. Yale's WINS model doesn't rely on replication anyway.
NetBIOS names are defined to be 16-byte values, and Microsoft breaks them into two parts. The first 15 bytes are the "name" field for the object or service that is being referenced, and the last byte (the "suffix") is a type code which shows what kind of service the name refers to. For example a type code of 0x1C indicates that the name is that of a Windows NT domain. This use of the last byte for the type code is why NetBIOS names are limited to 15 characters in the windows world.
Client systems typically register several names with WINS corresponding to what services are running on that client and what user is logged on at the time.
For more information on what the various NetBIOS suffixes mean, which is useful to know if you have to deal with WINS or NetBIOS name tables, see KB article Q163409.
How WINS Works
Registration of information in a WINS server:
Basic operation of WINS is fairly simple. Windows systems can define one or more addresses for WINS servers in their TCP/IP properties to interact with. For NT machines, only two WINS servers can be defined (a "primary" and a "secondary" server). For Win9x and Windows 2000/XP machines, more are allowed though two is usually all that's needed.
During network initialization on the client, it contacts the first WINS server listed and will attempt to register information such as the name of the machine and its IP number, along with entries other services that are running on the client such as the computer browser service. A single machine may register many times depending on what functions it is performing.
Dynamically-registered names have a default lifetime of one week (?) and will expire and be purged by WINS if they are not renewed by the client.
For a list of names registered by a client, see KB article Q119495.
Records can also be inserted manually into WINS servers. These are called static records and will never expire.
WINS also has the ability to "replicate" information from one server to another automatically. This has always been the the most problematic aspects of WINS -- replication has a tendency to result in corrupted WINS databases -- and we discourage its use. The way that Yale uses WINS minimizes (or eliminates) the need for replication.
Clients query WINS servers in order to locate machines, domains and/or services.
The client specifies a name to request information on as well as a record type in order to get what it wants. For example, a client can query a WINS server to find the IP number of a domain controller for a specified domain by sending a query for the name of the domain and a suffix (type) of 0x1c. The WINS server, if it has a corresponding record, will return an IP number (or a list of IP numbers) that correspond to that record.
Queries can also be made to locate users by name (to find out which computer(s) they are logged on to), by service (to find out which computer is the browse master for a subnet, for example) and in other ways.
It is important to know that WINS server queries are not handled like DNS server queries. A client will attempt to contact the first WINS server listed in order to resolve a name. If that WINS server does not have an entry in its database that matches the query or does not respond, the next WINS server in the list is tried until the list of servers is exhausted.
[ Note: The list of methods that Windows uses to attempt to resolve a name expressed in netBIOS format is extensive and incorporates not only WINS but DNS queries and local broadcast mechanisms. For a list of the methods used, see KB article Q142309, among others. There are also many other KB articles that talk about how each of these methods work. ]
Putting it all Together: WINS at Yale
Our recommended model for WINS uses several factors in combination with each other to produce a "layered" WINS structure that requires minimal administrative interference, gives all client machines easy access to the resources they interact with, and doesn't require replication in order to provide near-total WINS coverage from the client's perspective.
The "Behavior" elements
There are two "behavior" elements that we can keep in mind.
- Windows clients normally interact in a predictable pattern. Client machines need to "know" about all of the machines in their immediate neighborhood but don't need to interact with a large number of machines from other areas. For example, a client system in the Astrology department will mostly be interacting with clients and servers within that department.
- Contact with machines from "outside" the immediate vicinity is usually limited to a small number of high-visibility systems. For example, some users in the Astrology department might interact with a group of servers that hold financial or other information that are centrally maintained, but are also not generally interested in interacting with client systems or servers from another department.
Build WINS coverage that matches usage patterns
In order to give a client system easy access to everything they need to use, we build a WINS structure that matches the usage pattern of the clients:
- Establish a WINS server for each "group". A WINS server is put in place for each "group" of machines, such as the Astrology department. A good way to do this is to have WINS running on one of each department's servers. Groups can be cut as large or small as is practical. [ Note that this will allow name conflicts to exist in the Non-Win2K world -- if two client machines with the same name are built in two separate departments, they may never "see" each other because they don't use the same WINS server. In Windows 2000, the machines will have a name conflict within the AD that will need to be resolved. ]
- Have a central WINS server that is aware of as many high-visibility machines as possible. If your organization is mainly windows-based, this is fairly easy to do - install WINS on one machine, and then make sure that its IP number is the FIRST entry in the WINS server list of all other central servers that clients need to access. This way you have created a WINS server that knows about every important server in the central structure.
Configure clients so WINS will always have the answer they're looking for
- Configure all clients to have their "local" WINS server listed as the first WINS entry, and the central server listed as the second entry. Because of WINS' fall-through nature for name resolution, the client will first ask the local server to respond to a name query. If the local server doesn't know, then the client machine will ask the central WINS server. With this setup, the odds are VERY good that one of these two servers will have the answer to the query because of the ways that users normally interact with servers and services.
- Use static records to fill in any gaps. There will occasionally be "holes" in this coverage. If, for example, the Mathematics department runs a server that is a high-visibility machine (say a distribution point for some software), then machines in the Astrology department will not be able to resolve its name through WINS because neither of the servers that an Astrology client will "ask" will know the answer.
To solve this, insert a static record for the Math department server's name in either the Astrology department's WINS server or the central WINS server. Since changes to the WINS database take effect immediately, the Astrology clients (and anyone else in the organization if you put the record in the central WINS server) will immediately be able to interact with the Math department server without further problems.
The decision of whether to insert the static record in the local or central WINS server can be based on the machine in question. If it's to be widely used (say from many different departments) then the entry should be made in the central server so that it doesn't have to be related in many departmental WINS servers. If the interaction is basically from one department to another, then the entry can be made in the department-level WINS server to avoid cluttering up the central server's database.
This model works exceptionally well for us here at Yale.
If you have questions, please send email to Ken Hoover.