Would You Like to Solve Half of the Problems in Microsoft Networks?
Iím a systems engineer. Systems engineers deal with the problems. And I had and still have, many of them. Some of them are simple, some of them are very (sometimes too) complex to solve.
When I analyze the reasons of the problems I saw that approximately half of the problems are caused by the inability to resolve names to IP addresses in Microsoft Networks. Let me explain this.
You know that every entity on the net has a unique IP address differentiating it from the others. But the IP address is a hostile parameter for us, mortal human beings. So, we use computer names to ease the access to the resources on the computers.
We use the computer names, but TCP/IP uses IP addresses. So, we must find a solution to resolve the names of the computers to IP addresses. And this is where the problems begin. You must find a way to resolve the names into IP addreses. This problem is even bigger in Microsoft environments because the computers with MS Operating Systems (OSs) have two names; a NetBIOS name and a host name.
NetBIOS name is the requirement of the NetBIOS specification, which is created by IBM and Microsoft some time ago and specifies the operations in a network. NetBIOS specification says that computers must have a unique NetBIOS name, up to 15 characters.
On the other hand, host names are more flexible. They can be up to 255 characters.
Pre-Win2K systems have both names which can be completely different. For example, the NetBIOS name of a Windows NT system can be MAILSERVER whereas host name for the same computer may be postserver.acme.com. This multiplies the problem of resolving names into IP addresses.
After Windows 2000, NetBIOS names and host names can not be so separate. The part of the host name up to 15 characters, before the first period, if any, is regarded as the NetBIOS names in Win2K systems.
In a Microsoft network, the names you see in Network Neighborhood (or My Network Places, in Win2K) are the NetBIOS names of computers and domains/workgroups.
If the computers had been all in the same network, the NetBIOS-name-to-ip resolution would be easier because broadcast mechanism could be used in that case, without configuring any other mechanisms. But there are subnets, that is different networks. And broadcast packets can not pass thru routers connecting different subnets. And even if we donít have subnets, we donít want to use broadcast mechanism in name-to-ip resolution because of the load it brings to every computer on the network. (Every machine gets and evaluates the broadcast packets, whereas the directed-or unicast packets are evaluated only by the target of the packet though these packets are also received by the other computers.)
So we should use WINS (Windows Internet Name Service-a misleading name because it has nothing to do with Internet) for NetBIOS name resolution and DNS for host name resolution. (In addition to DNS and WINS there are HOSTS and LMHOSTS files, but they are too outdated).
WINS is not solely used for name resolution. It also gives information about the services on computers. For example, computers can get the info about the domain controllers from WINS or they can use WINS to see if a particular service is running on a target computer, like messenger service).
DNS in Win2K
After Win2K, DNS also has a similar function, thanks to SRV (Service Location) records which stores info about the services on the computers. Win2K computers can interrogate the DNS servers for the location of some specific services. Win2K computers go to DNS for almost any information they need: They can locate domain controllers, global catalogs, etc. using DNS. Pre-Win2K computers can not do that: They will go to a DNS server only for the host name resolution (for example, to find out the IP address for www.acme.com). Pre-Win2K systems use WINS and broadcast mechanisms to resolve the NetBIOS names.
You can think that after switching completely to Win2K, you can get rid off Wins and use only DNS. But it is not the case in a typical network. Why? Because in your network there may (and are) many computers with pre-Win2K OSs. You can not simply use DNS. Even if your network consists purely of Win2K machines, you may have to use still WINS besides DNS. Because NetBIOS names are not used by solely computers but they are also used by some old applications, like Systems Management Server 2.0 and some modern applications like Exchange 2000 Server. These apps require the NetBIOS name resolution. Let me give some examples and explain these situations.
Outlook client -Exchange Server
Outlook is the number one client program for Exchange Server. Though you can use other client programs, only Outlook can get the most out of the Exchange Server.
Outlook client locates the Exchange Server by its NetBIOS name. When you try to configure Exchange Server service on an Outlook client you must supply it with the NetBIOS name of the Exchange Server (you can enter the IP address or host name of the Exchange Server in the initial configuration, but once connected to the server, this info will be replaced by the NetBIOS name of the Exchange Server). If the client can not resolve the NetBIOS name to the IP address, no connection to the Exchange Server can be made. This is a popular problem in Exchange environments. This problem may be frustrating in the networks with routers. Some computers (the ones that are on the same subnet with Exchange Server) can connect to the server without any problem while the others (the ones that are on different subnets) can not connect to it. The solution is simple: Install and configure WINS on a server and make every machine (including the Exchange Server) on the network a client of this WINS server. On some shops, more than one WINS server are used. If this is the case, do not forget to replicate the WINS databases to each other. Otherwise, again some of the computers can not connect to the Exchange Server because their WINS server does not know anything about the Exchange Server.
Sms client-SMS 2.0 server
SMS client computers use NetBIOS names of their SMS servers. So client computers must resolve the NetBIOS names of the SMS 2.0 servers to IP addresses. Otherwise, the clients can not connect to the SMS 2.0 server. The solution is the same as the Outlook-Exchange Server situation.
The other problems regarding the NetBIOS name resolutions are not being able to locate the domain controller. Hence no logon can be made by the users (remember that some users can still logon in this case because their logon credentials were cached in their local computers). No trust can be made between the domain controllers if the domain controllers can not locate each other using the NetBIOS names of the domains.
There are many problems which can be avoided by the proper use of DNS in Win2K environments. For example, if a user canít logon to the domain the most probable reason for that is not being able to connect to DNS server and so not locating the domain controller. It is solved easily if we check the DNS server address configured at the client and correct it. Another example is when we try to make a Win2K computer a member of a Win2K domain. In this situation member candidate must see the DNS server responsible from the domain. Otherwise the the process can not be completed. Other problems occur when we try to set up a second domain controller or set up external trusts between two Win2K domains in different forests. In both cases, if the machines can not locate the domain controllers setup will fail. The solution is simple again: Make sure that machines ďseeĒ the appropriate DNS server containing the domain records. If they see the correct DNS server, then the problem may be that there is no SRV records in the DNS zones. In this case, stop and start Netlogon services at Win2K domain controllers so that they will register their SRV records to the DNS servers.
Use WINS and DNS together
For the time being, until we completely get rid off the the legacy OSs and legacy mechanism in the applications we should use WINS as well as DNS. If we install and configure WINS and DNS, we may avoid half of the problems in Microsoft networks.