What is a Network Client?
Whether you are administering a network, troubleshooting a problem, or designing a solution it is invaluable to understand the role that your device plays in the network. As I worked the phones at Microsoft’s US Senior Escalation Center I often found confusion caused by the use of the terms “Client” and “Server“. My goal in this article is to help us better understand and use these terms so that we can be more efficient in our day-to-day work and processes.
It is first important to remember that no device on a network runs on its own. Nearly EVERY device is both a server and a client, no matter its role or OS. A network Client is at its core is a device that initiates a network connection; while a Server at its core is a device that receives this connection. It does not matter if it is running Windows Server 2008, XP, Linux, Mac, or whatever you have. I will give two examples, based on real calls I worked on, to help illustrate this point.
XP to XP
One of this first calls I took where this confusion over roles became overwhelming was a small business who kept their file shares on different XP workstations based on the role of the user (i.e. One was an architect so all the architectural drawings were on his box, while another was a secretary or admin so all the administrative files were on hers).The trouble came when a user tried to connect from one XP workstation to one of these shares on another XP workstation. Though the problem was rather involved, the call was not escalated (through 4 lower tiers of support) to me because of the configuration problem, but rather because the previous engineer’s on the Microsoft side all struggled to help the customer understand the roles that each of these XP workstations were playing. When we were discussing the problem on the phone and in the action plans presented, I used the term Client to refer to the XP workstation initiating the connection and the term Server, to refer to the XP workstation sharing out the directory. In one specific step in the action plan I asked the customer to perform an nslookup on the Client and record the output. Not understanding the roles, he performed it on the machine acting as a Server. This ended up causing some delay and frustration for the customer as we had to break from troubleshooting to clarify terminology, and then the customer had to once again go about gathering the requested data. XP is clearly a client operating system but from a networking perspective, the designation of Client and Server are based on the initiator and the recipient of that connection. Once we got past this step of understanding the roles, the customer was able to conceptualize the situation, and we were able to continue troubleshooting on the same page.
2003 to 2003
A second call that had me pulling my hair out was a very heated issue where the customer had a critical website that was not able to display their data. This web page was hosted on a 2003 Server running IIS and presented dynamic pages which were built off of a SQL database loaded on a separate 2003 backend server. Web clients, from any OS, would connect to the IIS service, and given the page configuration, the IIS service would connect to the 2003 server running SQL to gather the information needed to create and present the data to the web client. In this scenario the 2003 server running IIS played the role of both Client and Server. It was the Client to the SQL Server when it needed to pull data from the database to populate the page. It acted as the Server to the web client requesting the web page.
At one point during this call we found ourselves nearly unable to progress Ddue to the high-security nature of the client, I was not allowed to see or touch the configuration of these clients or servers. I had to explain each step in excruciating detail to resolve the problem as the customer did not comprehend the roles that each server was playing – and when each machine was playing what role. This dramatically delayed the progress in resolving the issue as at each step I had to specifically define the name of the machine that was acting as the Client or the Server and why it was in that role for each step. This quite literally caused each conversation and each action plan to be at least twice as long as it needed to be. In the end we found that the problem was between the machine running IIS when acting as the Client to the Server running the SQL instance. And it was the eventual understanding of the roles in this connection that allowed the customer to see the problem in the console that I myself was unable to see (or even be told about) because of their security controls. Not until we took ourselves out of the problem to come to a mutual understanding of the roles that these servers where playing were we able to effectively troubleshoot and resolve the issue.
Summary
In both of the above cases I hope that the long term help that I was able to provide these customers was the ability to understand the Client/Server roles and under what circumstances each networked device fits into these roles. I believe that this understanding will help them in the long-term while driving troubleshooting of problems themselves. I can tell you that it is this type of conceptual understanding that has empowered me to fix issues involving technologies where I have no product knowledge (though valid product knowledge is always valuable).
The most important part to remember is that a Client initiates a request for connection to another device (the Server). The very initiation of this conversation on the device means that it is a Client, reaching out to utilize a service provided by another network device. This “other network device” is providing a service to Clients on the network, and so is in that vein is a Server, no matter the OS. Even that Server however at times needs to go onto the network and initiate communication, where it becomes the Client.