PCs linked using Microsoft networking use NetBIOS to communicate with each other (although this is beginning to change with Windows 2000), and in order for one PC to find another (e.g. for a workstation to locate a domain controller), the PCs involved must each have a unique identifier, namely the the NetBIOS or Computer Name. For Windows 95, 98, Me and NT the NetBIOS name is entered in the Network Identification tab in the Network control panel while in Windows 2000 the Network Identification tab in has moved to he System control panel.
In a simple arrangement, when a PC with a NetBIOS name of FROG starts up on subnet A, it broadcasts its existence onto that subnet. Usually that broadcast will not be routed outside the subnet. Within subnet A, one or more PCs will act as a Browse Master and maintain a browse list of the NetBIOS names of all computers currently active on the subnet. Generally any other Windows PC on that subnet will have no trouble in locating it, either explicitly or through browsing the network via Network Neighborhood. For example if a second PC, TOAD, also on subnet A, needs to access a share on FROG, it can use the browse list to locate FROG, or if FROG is not on the browse list it can broadcast to locate it. (Note that Windows 9x PCs will not appear in the browse list unless File and Print Sharing is enabled).
Now since in general NetBIOS broadcasts do not cross routers, if a third PC called NEWT on subnet B needs to be able to access a share on FROG, it will not be able to find FROG. FROG has not broadcast its existence onto subnet B, so no PCs on this subnet will know about it. A method of name resolution is required and this is where WINS comes in. If NEWT and FROG are both both configured to use the same WINS server, the something along the lines of the following steps will take place.
- When PC FROG starts up, it sends a registration request to the WINS server for name FROG, together with FROGs IP address. So long as the name FROG doesnt already exist in the WINS database with a different IP address, the request will be accepted, and the mapping between FROG and FROGs IP address will be entered into the WINS database.
- When PC NEWT starts up, a similar process takes place to register NEWTs name and IP address into the WINS database.
- When someone tries to access a share on FROG from NEWT, NEWT will query the WINS server for the name FROG. The WINS server will respond giving FROGs IP address, and NEWT will be able to access the share on FROG.
It is not simply the PC name that is registered in the WINS database. In fact, the services that the PC is running are also entered. For example, a typical server will have three entries — one each for the workstation, server and messenger services. A domain controller also registers entries for the domain name; an Exchange server adds a couple more entries, as does IIS, and so on and so forth.
Using WINS does not mean that you can browse the network to find the machine that you want. If the machine is on a different subnet you still may not be able to see it. This often seems to worry people unduly — it seems that we have got used to being able to browse the network to find the machine that we want. However, so long as both machines are using the same WINS server, they will be able to find each other. This behaviour is really very similar to the way in which the DNS works. You cannot browse for linux.ox.ac.uk, but if your PC is set up to use the DNS correctly, you can log into linux.ox.ac.uk or copy files between PC and linux.ox.ac.uk. The fact that we cannot browse for linux.ox.ac.uk doesnt worry us, so we need to get used to the fact that we cannot necessarily browse for all Microsoft resources in the university. With Windows 2000, Microsoft is moving away from NetBIOS names towards using the DNS for name resolution, so we need to get used to not being able to browse for networked resources.
When browsing the network, leaving aside Novell servers, you may only see workgroups and PCs on the same subnet as your PC. So long as your PC is using the central WINS servers you should be able to access PCs on other subnets even though you cannot browse to them. However there are two factors that may increase the number of PCs that you can see under Network Neighborhood. The first is the networking protocols that are loaded on the PC and the second is the presence of an NT or 2000 domain controller on the subnet.
Microsoft networking uses NetBIOS. However, NetBIOS can use the TCP/IP protocol (when it is generally referred to as NBT or NetBT), the IPX/SPX protocol or the NetBEUI protocol, which can introduce a few complications! A PC using NBT can actually only communicate with other PCs running NBT. A PC using NetBIOS over IPX/SPX can only communicate with other PCs using NetBIOS over IPX/SPX, and similarly for PCs using NetBIOS over NetBEUI. It is also quite possible for a PC with more than one protocol installed to be communicating via NetBIOS over all of them at once! Within a subnet, there will be a different browse list for each protocol. For NetBEUI, however, the browse list is maintained university-wide.
We recommend that you use NBT and it is the only one that the WINS servers support. By default, if you have TCP/IP installed, NBT will be enabled, so you dont generally need to alter anything manually.
It is the NetBEUI protocol that tends to change what you can browse quite dramatically. This is because it is a non-routed protocol and it is not blocked at routers, which means that you can see PCs on other subnets that are also using NetBEUI. Use of NetBEUI is not recommended and it is best removed unless absolutely essential. Although you may like being able to browse more parts of the network, you will never see all PCs because you can only see those PCs that are also using NetBEUI and on some subnets it is filtered out completely. Using NetBEUI increases network traffic because broadcasts are university-wide, and with Microsoft moving away from name resolution via broadcasts and WINS to using the DNS, browsing is on the way out anyway.
If a PC is on the same subnet as an NT or 2000 domain controller, and is a member of the domain (for NT and 2000 workstations) or is a member of a workgroup with the same name as the domain (95, 98, Me, NT or 2000 workstations), and the domain controller is using the central WINS servers, you will be able to see a large number of domains around the university (currently around fifty). This happens because a domain controller that is configured to use WINS pulls the browse lists of all the other domain controllers using the same WINS server and adds them to its own browse list. As a result you can browse many more PCs around the university.
As soon as you need to access Windows PCs on a different subnet, you need a method of name resolution, and that probably means WINS. In particular, if you have an NT or 2000 domain that is split across more than one subnet, WINS is pretty much essential (unless you really like editing LMHOSTS files). This probably means that most units of any size with an NT or 2000 domain need to use WINS. Any workstation that needs access to the full version of OxLIP (i.e. not the web version) also needs to use WINS. There are two ways of implementing WINS and both are used within the university.
OUCS runs two central WINS servers that can be used by any PC in the university. The two servers regularly replicate their databases to each other (every 10 minutes) so that any PC registered with one server is also known about by the other. Generally PCs are configured with the addresses of both servers to provide redundancy in case one server fails. Configuration is simple and the only prerequisite is that you name your PCs in accordance with the Naming Standards. This is because NetBIOS names must be unique within the WINS database, and hence potentially within the whole university — in the event of a clash, networking services on one of the PCs will be disabled, which is particularly catastrophic in the case of a server.
It is very simple to set up your own WINS Servers and Microsoft provide plenty of documentation. However, if you are implementing WINS for the first time then we recommend that you use the central WINS servers instead. The problem with setting up your own servers is that they will have no communication with the central servers and will not know about PCs that are registered centrally (currently several thousand PCs and around fifty domains). This means that if your PC tries to locate another PC in a different unit, it will not be able to locate it. Although it is possible to add entries in manually, this is a nuisance to maintain, and for domains it doesnt always work reliably. If you do use local WINS servers we do recommend at least naming your servers according to the Naming Standards. This is because NT and 2000 servers are either difficult or impossible to rename, so if you ever want to change to using the central WINS servers, using the naming standards should mean that there wont be any major problems in doing so.
A number of units have been quite happily running local WINS servers for some time, and many will undoubtedly continue to do so without problems. However, if it is necessary to move from using local WINS servers to using the central ones then there a number of things that we can do to help. In outline we would probably set up replication temporarily between the central servers and the local ones to allow the change to take place gradually without interruption of service. We would also check that there wouldnt be any major name clashes (i.e. between servers). If you would like to change from using local WINS servers to using the central ones, please e-mail winsmaster.