Windows Networking Concepts Everyone Should KnowPost Date: 2020-12-20 |
Post Reply
|
Author | |
ErikW
Newbie Joined: 26 Aug 2020 Online Status: Offline Posts: 22 |
Quote Reply
Topic: Windows Networking Concepts Everyone Should Know Posted: 20 Dec 2020 at 9:47pm |
Troubleshooting Windows networking for file and printer sharing can be a
frustrating experience. It can be difficult to tell if your problem is
because of network configurations that don't work with Windows
Networking, or problems with your Windows Network settings. There are
some simple concepts that can help you decide what isn't working, and
what to check to solve the problems.
The very first concept that most people overlook is that Windows Networking has three separate functions. I am going to list those in the order that you normally use them, but surprisingly, you only need the third one to use Windows Networking. - Network browsing to display a list of computers - Name resolution to get IP (or MAC) address from a computer name - Server Message Block (SMB) client/server protocol to log in and transfer information Most people never think about how Windows knows what computers are out there on the network. You may know that computers are grouped into "domains" that are either a Workgroup or Windows Server Domain. The network computer Browser is a service that runs in Windows, and it uses broadcasts on UDP port 138 and direct communication on UDP port 138. UDP port 138 is the NetBIOS Datagram service port. When the computer Browser is not working, you can still access computers if you know their network names. You do that either by creating a shortcut to the computer and share name, or by typing in the computer name followed by the share name. For example, "\\COMPUTERNAME\Sharename\...". Broadcasts present a problem because they don't usually travel between IP sub-networks, through some switches, and on some wireless networks. There are solutions to fix those problems but sometimes it's just better to configure shortcuts with the correct names. How does the Browser service work? Essentially, server computers broadcast their name when they first start up, and then on a periodic basis afterward. By "server" I mean any computer that happens to share files or printers, whether that computer has a Windows Server, Windows Workstation or Windows Home OS. If a computer doesn't have file and printer sharing service running, then it doesn't appear in the browse list! There are some computers known as "the master browser" and "backup browsers" in a Domain/Workgroup that listen for those broadcasts and maintain a list. The Browse list has all of the computers that the master and backup browsers know about. Other computers listen for broadcasts identifying the master/backup browsers, and then ask those computers for the list. So, how does Windows choose which computer will be the master browser for a Domain/Workgroup and which will be the backup browsers? That process is done by a committee of the network computers, and is known as Browser Election. Computers that are more desirable get preference over less desirable computers. A server OS is more desirable than a workstation/home OS, and newer versions of Windows are more desirable than older ones. There are also two registry keys that you can set to change how desirable a computer is. One key, "IsDomainMaster" can be set to "True" on computers that should be chosen as a master browser. Another key, "MaintainServerList", can be set to "No", "Auto", or "Yes" depednding on whether the computer should never, maybe, or always try to be a backup browser. If you want your computer Browser service to work well on your network, then you will designate a relatively new, fast, stable computer that is on most of the time as the master browser. You should designate other computers to be backup browsers if they are on a lot of the time and relatively powerful. Computers that are power cycled frequently, slow, or unreliable should be set to NOT ever act as backup browsers. All of those are just hints to browser election, because it will choose from the available computers whenever computers coma and go on the network. Each workgroup/domain has a master browser computer and at least one backup browser. Depending on the number of computers on the network, there may be additional backup browsers. With a small number of computers, having more than a single workgroup/domain can make browsing less reliable. To make computer Browsing work, you may need to program switches or IP Gateways to forward the UDP port 138 broadcasts, or use the LMHOSTS file in Windows to tell computers about designated browsers for their workgroup/domain and others. On networks that block or garble broadcasts, have computers power cycling frequently, have frequent disruptions in communication, or slow computers with outdated Windows software, you may never be able to make the computer Browser function work reliably. A couple of designated computers for computer Browsing that are left on all the time with reliable communication is all that you really need. The reality is that many households turn computers on and off randomly and have a mixture or computers and Windows versions. Don't get frustrated trying to make an unworkable combination of computers function reliably for computer Browsing. If you've been paying attention, you've noticed a few things. I mentioned NetBIOS Datagram Service using UDP port 138, but what if you aren't using IP protocol on your network? NetBIOS is actually a separate protocol, and it can use TCP+UDP/IP, Microsoft NetBEUI, or Netware IPX/SPX protocl. You may have never heard of the last two, but they were once used more than TCP/IP. In order for the Browser service to work with TCP/IP, you must enable NetBIOS over TCP/IP (NETBT). The "NETBT" interface includes UDP/IP for Browsing. In the advanced TCP/IP settings there are options to enable or disable NetBIOS over TCP/IP. That is often overlooked and can prevent Windows Networking from functioning. Another thing that you may have noticed is that I have only mentioned computer names, not computer IP or MAC addresses. The Browser service only provides a list of server names. It does not provide any information about the addresses used to communicate with those computers, or the shares/services available on those computers. The second Windows networking function that I mentioned is name resolution. Windows can do computer name to address resolution in a number of different ways, and it may try to use more than one. On computers not using TCP/IP, the computer names resolve to a MAC address. When using TCP/IP, computer names resolve to an IP address and the normal ARP (Address Resolution Protocol) of Ethernet is used when the MAC address is needed. While ARP is not part of name resolution, it is a necessary part of TCP/IP on Ethernet. The first, and oldest method of name resolution is NetBIOS Name Service. To resolve computer names to IP or MAC addresses, NetBIOS Name Service broadcasts on UDP port 137. When computers receive a broadcast request to their name, they respond using UDP port 137, TCP port 137, or a broadcast on some other protocol like NetBEUI or IPX/SPX. NetBIOS Name Service is usually how computers on home networks find out the addresses of other computers. Since NetBIOS Name Service uses broadcasts, all the same broadcasting problems can happen as with the computer Browser. Most people never go further than this default way of resolving computer names, and simply get frustrated if it doesn't work with their network configuration. The next method of name resolution is actually so simple, most people overlook it. Configuration files on your computers can specify the computer names and their addresses. You can define computer names and their addresses in a file named "hosts" in Windows. The hosts file is used for any computers communicating over IP, and it works just as well for NetBIOS over TCP/IP (NETBT). If you aren't using TCP/IP, you can do the same thing for MAC addresses in a file named "LMHOSTS" (LAN Manager Hosts). You can often just copy the same files to every computer since it doesn't hurt for a computer to have an entry for itself in the file. Or, just remove the entry for the host where the file is located. If you have unreliable broadcasts on your network, configuration files may be your only good choice. Note that this doesn't solve the problem of IP to MAC address resolution (done by ARP). You have to use things like static ARP entries or router proxy ARP if computers can't respond to broadcasted ARP requests. When using TCP/IP there are two more methods to resolve computer names into IP addresses. But most home networks have neither of those. They are the normal DNS (Domain Name Service) used with TCP/IP and a Microsoft protocol named WINS (Windows Internet Name Service). You may be thinking that you have Domain Name Service on every computer and wondering why you can't use that. The problem is that you don't have a DNS Server computer or router that your computers can register their names with, or query for those registered names. Your Internet Service Provider is certainly not going to let all of your computers register their names, nor respond to queries for those names. If your home network has any name on the ISP's network, it will be one assigned by them to correspond to your global Internet address. Windows Internet Name Service runs on a Windows Server OS, but you can also run it on Linux as part of the SAMBA server. Most people don't bother setting up a special name server on their network, but it is possible to do that. In some cases, you may be lucky enough to have a router that can support either a DNS Server or WINS Server function. Windows may try any or all of the methods that I listed to resolve names, but that can make the process very slow if most of them aren't working. You can change or remove network bindings or settings to eliminate the ones that you know will never work, but that requires a lot of knowledge and newer versions of Windows have removed the user interface for doing that. At last we come to the SMB (Server Message Block) protocol used to actually transfer files between computers along with the necessary authentication. As I mentioned, this is really the only protocol that you need to share files and printers. You can type in computer names and create configuration files to resolve the computer addresses to do without the Browser and name resolution. You can also type in an IP address instead of a computer name if you don't want to bother creating configuration files. You might think that SMB would be simple, but it is probably the most complicated subject because it touches on all the different kinds of user authentication and services available through SMB. To add confusion, there are multiple versions of the SMB protocol, SMB/CIFS, SMB 2 and SMB 3. I am going to cheat and simply say that SMB provides the protocol and services to authorize (authenticate) users, find out what files and printers are shared, transfer data, and change the properties of some shared files or printers. SMB started out using NetBIOS Session Protocol through TCP/IP port 139. That eventually presented some problems because port 139 serves both a NetBIOS session function as well as an SMB communication function. Newer versions of Windows have moved the SMB protocol to TCP/IP and UDP/IP port 445. Newer versions of Windows actually try to open both port 139 and 445, and then disconnect port 139 if 445 successfully connects. I'm not exactly sure what Windows does with UDP port 445. Port 445 is also intended to work across sub-networks, while port 139 is only intended to be used for older operating systems over local networks. Making Windows Networking function across multiple IP sub-networks involves configuring a number of things such as "LMHOSTS" or "hosts" files on computers, DNS Servers, WINS Servers, IP gateways and routers. What you do to configure the three parts, Browsing, Name Resolution and Server Message Block (SMB) will depend on the functionality you want and how you decide to accomplish that. If I had to give you one piece of advice about troubleshooting Windows Networking it would be this. Start out your testing by using just the SMB protocol. To do that, type in a computer's IP address in a file Explorer Window. For example, "\\192.168.1.24\". On really old Windows versions, map a network drive because you can't type addresses in Explorer windows. If that doesn't work, your problem is either basic TCP/IP communication, authentication of your user account, or the server on the other computer is not running. When I need to communicate to a computer and I know that there are gateways, routers, WiFi and other possible obstacles, I go right to using the IP address of the server computer. If you're only going to access a computer once in a while, what is the point of fixing all of the problems with computer Browsing and Name Resolution? Always keep the three major parts of Windows Networking in mind, and if possible troubleshoot each one separately. Make sure that you know how Name Resolution is done on your network, so you can troubleshoot NetBIOS Name Service, DNS, WINS, or the configuration files "hosts" and "LMHOSTS". When in doubt, assume that names are resolved by NetBIOS Name Service. The weakest part of Windows Networking is the computer Browser service. That's the last thing to troubleshoot, and in some cases the network configuration can prevent it from ever working properly. You can test IP protocol in a few different ways. One is using the "ping" command. Don't forget that also uses ARP (Address Resolution Protocol). It's a good idea to look at the ARP cache before and after doing "ping". Use "arp -a" to dump out everything in the ARP cache on a computer. For complicated networks that go across multiple IP gateways, you can use a command named "tracert" to see exactly how communication travels between your computer and the other one. Most people won't find "tracert" very useful for troubleshooting Windows Networking problems. It can be very useful for figuring out which router on the actual Internet is causing delays or interruptions in your communication. There is a command named "nslookup" that will test name resolution using all of the available methods. Use that with the computer name to determine if computer names can be resolved. The "nbtstat" can display information about NetBIOS over TCP/IP if you are using that for name resolution like most people. Also, keep in mind that name resolution on the actual Internet is a totally separate thing from computer name resolution on your local network. I also recommend a program named Wireshark for looking at network communication. It decodes most protocols including the ones I mentioned. You will have to install it on one of the computers, client or server that are communicating. It really doesn't hurt to install it on every computer, and you can easily disable it until you need it if that is a concern. What else you might want to know about Windows Networking will really depend on how you intend to use it. Home users are probably more concerned with how to make a small local network function. If you have to support a large corporate network of computers, you will need a much more complete knowledge of TCP/IP, Domain Name Servers, Windows Authentication, file permissions and user rights, etc. Edited by ErikW - 24 Dec 2020 at 3:42pm |
|
ErikW
Newbie Joined: 26 Aug 2020 Online Status: Offline Posts: 22 |
Quote Reply Posted: 29 Dec 2020 at 5:53pm |
For Windows 10, the Computer Browser protocol is no longer used to find Windows computers on the network. Newer versions of Windows 10 have made the SMB 1 protocol including the Computer Browser optional. If you have older computers with Windows XP and earlier, you may want to enable SMB 1 and the Computer Browser, but review the security issues with enabling SMB 1. Windows 10 now uses something named WS-Discovery to find other computers sharing files and folders. There are a few different ways for WS-Discovery to find other computers, but the default method is to send IP Multicast (limited broadcast) messages that other computers can receive and respond to. Multicast broadcasts are only received by computers that join the same IP multicast group. If IP multicast is used to send multicast messages they MUST be sent using the following assignments: • DISCOVERY_PORT: port 3702 [IANA]• IPv4 multicast address: 239.255.255.250 • IPv6 multicast address: FF02::C (link-local scope) Other address bindings may be defined but are beyond the scope of this specification. Messages sent over UDP MUST be sent using SOAP over UDP [SOAP/UDP]. To compensate for possible UDP unreliability, senders MUST use the example transmission algorithm in Appendix I of SOAP over UDP. When you enable network discovery on Windows 10, that also enables the WS-Discovery protocol, but you may have to configure the firewall to allow the multicast ports and addresses. WS-Discovery requires IP protocol. All the same broadcast concerns still apply to WS-Discovery. In addition computers usually have to coordinate with switches and routers to receive multicast messages. Even if WS-Discovery does not find computers, you can still use shortcuts or type in the computer names to access the computers. Name resolution in Windows 10 adds a number of methods that I didn't mention, and you can still use NetBIOS Name Service but you may have to enable NetBIOS over TCP/IP. You can also still use the "hosts" and "LMHOSTS" files to resolve computer names to addresses. Just as before, you can type in an IP address instead of a computer name to avoid the need for name resolution. The three basic parts of Windows Networking are still there, but they have different names and use different methods than I described. When you have a mixture of Windows versions on your network, you may need to enable multiple methods of network discovery and name resolution.
Edited by ErikW - 29 Dec 2020 at 5:54pm |
|
hoserator
DS Veteran We don't need no stinking "Avatars" ! Joined: 08 Oct 2014 Online Status: Offline Posts: 7942 |
Quote Reply Posted: 31 Dec 2020 at 12:48am |
Wow, You, sir, must be in the training/education field. You write ups are beyond excellent. There is a lot going on in the backround to make these systems work as user friendly as they are.
|
|
Cretae
DS Veteran Joined: 22 Mar 2010 Online Status: Offline Posts: 7328 |
Quote Reply Posted: 31 Dec 2020 at 3:40am |
+1
Don't think because we are rendered somewhat speechless from the depth of your essays, that we don't appreciate them. Please feel free to educate away whenever moved to do so! |
|
ErikW
Newbie Joined: 26 Aug 2020 Online Status: Offline Posts: 22 |
Quote Reply Posted: 02 Jan 2021 at 2:39pm |
Thanks for taking the time to tell me that you found the posts to be informative. So far, I've just been posting things that I had to struggle with when setting up my new machine from Digital Storm.
Not everyone can take Microsoft training courses to learn these concepts. I know that I can't. So many people have helped me with information and software that I want to give something back when I can. And, it's always nice to hear that someone made use of my efforts. Even one person is enough to make it worthwhile. |
|
Post Reply |
Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |