Some users have questions about how SharePoint works. SharePoint consulting services, a solution to facilitate collaboration, content management and productivity, has enjoyed growing success over the past ten years. However, users still don’t fully understand how SharePoint works. For them, SharePoint is a veritable treasure trove of business-oriented functions and features that magically appeared one day to make their lives easier – magic dust, unicorn songs and rainbows.
If only it were that simple.
In reality, from licensing to deployment, SharePoint admins go through a comprehensive process that includes defining performance requirements → designing the server farm architecture (see below) → developing the server farm and installing SharePoint → test → define and create the information architecture → more testing → content migration → MORE of tests → and finally, nervously granting access to users and declaring SharePoint operational. This is when the day-to-day tasks of performance monitoring, content and server farm assurance, settings and configuration management (service applications, permissions, provisioning, etc.), and governance and management begin. compliance.
No trace of unicorns. That’s good enough for business users, because they need to know how SharePoint works at least as much as knowing how to configure Active Directory (ie not at all). But if you are not a simple user, but rather an administrator in charge of the architecture/configuration/management of SharePoint, it is essential to understand the basics. Although a full deployment of SharePoint is beyond the scope of this position, let’s take a look at one of the most important concepts in SharePoint: farm roles and how they interact.
How SharePoint Works: SharePoint Server Farm
Clearly, a SharePoint server farm is a set of servers that work together to fulfill SharePoint roles, thus making SharePoint work. If you are unfamiliar with this term, think of these roles as different tasks that each require specific skills. Once you’re ready to configure SharePoint, you configure each server on your farm to perform one or more roles.
An appropriate analogy to describe roles would be a team working together toward a common goal (long live collaboration!). Take for example a restaurant team. In a restaurant, the hostess is there to welcome and seat customers, the waiter to take orders and then serve them, and the kitchen staff to prepare the dishes. If you remove the hostess, the customer will not have a place.
SharePoint
If you remove the server, the customer will never be able to place an order, or eat, or even receive a simple glass of water.
You get the idea. Of course, one person could do all of these tasks, like in a small cafe where the person behind the counter also takes orders, tells you to sit anywhere, and makes and serves your bagel for you. However, this only works if the place is not crowded with people, in which case that person would quickly be overwhelmed. Your server farms work the same way: a single server can adopt all the roles, or you can distribute them across multiple servers to optimize performance.
In SharePoint there are three roles (officially defined in the SharePoint Setup Wizard with some new roles in SharePoint Server 2016 ). These roles are: Web Front End Server (WFE), Application Server, and Database Server.
How SharePoint Works: Web Front Ends (WFE)
The front-end web server is supposed to be the connection point between users in SharePoint. When a user opens a browser and visits a SharePoint URL, they are actually addressing a front-end web server. User requests and responses to requests always go through a front-end web server, and are never sent directly to/from an application server or database server.
Front-end web servers host web applications (IIS web sites) that are the top-level sites for users and other SharePoint components. The SharePoint application is installed on your front-end web servers, which should be optimized to receive and process user requests.
How SharePoint Works: Application Servers
Application servers host service applications. But what is a service application?
To understand SharePoint service applications, just think of a car. What is the purpose of an automobile? Getting you from A to B of course. But here it is: do you need a car stereo to get from A to B? The answer is no. You need the engine, transmission, steering, inflated tires, brakes, etc., but not the radio. That said, it’s nice to have the radio, isn’t it? Does the radio offer features that make your trip easier and more enjoyable? Yes ? That’s exactly what SharePoint service applications do: they provide specific functionality that makes SharePoint work for users or the server farm. The search function is a good example. You can run SharePoint without the search feature if you want,
SharePoint is installed on your application servers, which are optimized to best provide the services configured on them. Service applications can even be configured across multiple servers to improve performance. This is often what happens for the research function by creating what is commonly called a research farm. Users do not connect directly to application servers. Front-end web servers “talk” to application servers.
How SharePoint Works: Database Servers
Microsoft SharePoint is a browser-based collaboration platform. To which users upload content, including Office documents. PDFs, images, videos, exported emails, calendar entries, tasks. Contracts and project information. This allows them to take advantage of all the great features provided by SharePoint, and that’s what it’s all about. So, one might ask: what happens to all this content? Where does it end? To answer this question, you first have to understand where you do n’t want it to end up.
You don’t want user content on your front-end web servers. They have quite enough work: receiving, processing and responding to user requests. Resources (memory and storage) are not meant to handle user content in addition to their normal load.
You also don’t want user content on your application servers. They are busy hosting and responding to local service application requests. Just like front-end web servers, they lack the necessary resources.
Where does the user content go?
Ladies and gentlemen, tonight (like every night), the role of database server will be interpreted by Microsoft SQL Server!
Indeed, all this user content (and also other elements) ends up in SQL Server databases. And more specifically in SharePoint content databases. These databases are almost always on a dedicated machine because SQL Server. Is a demanding application that requires a lot of resources. And minimal latency to run SharePoint optimally. For this reason, SharePoint is usually not installed on your database servers, nor is it necessary. Your front-end web servers and application servers only need. To know the destination of the databases that you configure when installing SharePoint (or later).
SharePoint users never connect directly to the database server. This is not necessary since every user request is sent to front-end web servers.
How SharePoint Works: Roles in Action If this is all a bit fuzzy, here are some images to illustrate some logical server interactions that make SharePoint work. For the purposes of this article, these images show separate servers. But remember that roles can be run by a single server if needed (although this is not recommended for production farms).
