Learn the migration strategies your organizations need beyond lift and shift with our webinar, Out Hustle The Hassle: Office 365 Migration Prep and Planning
THE CONFERENCE MODERN WORKPLACE PROS CAN’T MISS
Some users ask, “How does SharePoint work?” Microsoft SharePoint, a solution for enabling collaboration, content management, and productivity, has developed a wide following in its more than a decade on the market, yet user understanding on how SharePoint actually works remains low. For them, SharePoint is a wondrous treasure chest of business-enabling functions and features that magically appeared one day to make their lives easier – running on fairy dust, unicorn songs, and rainbows.
Further your SharePoint knowledge with these more in-depth articles:
- What Is SharePoint? A Guide For Beginners
- Learn SharePoint Basics
- How to Master SharePoint Management
- 7 Helpful Office 365, SharePoint Customization Best Practices
- 4 Essential Content Management Tips for SharePoint Online
If only it was that simple.
In truth, from licensing to rollout, SharePoint admins go through an exhaustive process of: defining performance requirements → designing the farm’s server architecture (see below) → building the farm out and installing SharePoint → testing → outlining and creating the information architecture → more testing → content migration → EVEN MORE testing → and then, finally, nervously granting users access and declaring SharePoint open for business. It’s then that the daily tasks of performance monitoring, content and farm assurance, settings and configuration management (service applications, permissions, provisioning, and so on), and governance and compliance enforcement begin.
No unicorns in sight. That’s OK for business users, because they need to know how does SharePoint work as much as they need to know how Active Directory is configured (which is not at all). But if you’re not a user and are instead on the administrative side – tasked with architecting/setting up/managing SharePoint – understanding the basics is critical. While an entire SharePoint deployment is beyond the scope of this post, let’s take a look at one of the most important fairy-free SharePoint concepts: farm roles and how they interact.
How Does SharePoint Work: SharePoint farm
Simply defined, a SharePoint farm is the collection of servers that work together to fill the SharePoint roles, to make SharePoint work. If you’re not familiar with that term, think of roles as different jobs that each require particular skills. Once you’re ready to set up SharePoint, you configure each server in your farm to perform one or more roles.
A fitting analogy for roles is a team working together toward a common goal (yay collaboration!). For example: a restaurant crew. In a restaurant, you have the host to seat patrons, the waiter who takes the patron’s order and ultimately brings them their meal, and the kitchen staff who prepare the meal. Eliminate the host and the patron never gets a seat. Lose the server and the patron never gets to place an order, eat, or even get a lousy glass of water. You get the idea. Of course, one person could fill all of those roles – like in a small coffee shop where the person behind the counter takes your order, tells you to sit anywhere, and then butters and brings you your bagel. This only works if the place isn’t flooded with customers, though, as that one person would get overwhelmed quickly. Your farm servers work the same way, where a single server can play all the roles, or you can spread the roles out across multiple servers for better performance.
In SharePoint, there are three roles (formally defined in the SharePoint installation wizard alongside a few new roles in SharePoint Server 2016). These roles are the Web Front End (WFE), Application Server, and Database Server.
How Does SharePoint Work: Web Front Ends (WFEs)
The job of the WFE is to be the connection point for users into SharePoint. When a user opens a browser and visits a SharePoint URL, it’s a WFE they’re hitting. User requests and request responses always go through a WFE, and never directly to/from an application server or database server.
WFEs host the web applications (IIS web sites) that serve as the top-level sites for users, and other SharePoint components. The SharePoint application is installed on your WFEs, which should be optimized to receive and process user requests.
How Does SharePoint Work: Application Servers
Application servers host service applications. So what’s a service application?
To understand SharePoint service applications, think of an automobile. What’s the purpose of an automobile? To get you from Point A to Point B, of course. But consider this: Do you need a radio in the car to get from Point A to B? Answer: No, you don’t. You need the engine to run, the transmission to work, steering, inflated tires, brakes, and so on, but not the radio. But is it nice to have a radio? Does the radio provide functionality you want that makes your trip easier and more enjoyable? Yes? That’s what SharePoint service applications do: they deliver specific kinds of functionality to get SharePoint to work for users or the farm. Search is an example. You can run SharePoint without search if you want to, but having search is great!
SharePoint is installed on your application servers, which are optimized to best deliver the services configured on them. Service applications can even be set up across multiple servers for performance. This is often done for search, creating what is commonly called a search farm. Users do not directly connect to application servers. Application servers are “talked to” by WFEs.
How Does SharePoint Work: Database Servers
Microsoft SharePoint is a browser-based collaboration platform upon which users upload tons of stuff – including Office documents, PDFs, images, videos, exported email messages, calendar entries, tasks, contracts, and project info. They do this to take advantage of all the great functionality SharePoint provides, which is kind of the point. But it begs the question: Where does all that stuff actually go? To answer the question, the first thing to understand is where you don’t want it to go.
You don’t want user content on your WFEs. They’re busy being WFEs – receiving, processing, and responding to user requests. The resources (memory and storage) are not there for managing user content in addition to their normal load.
You don’t want user content on your application servers, either. They’re busy hosting and replying to requests for locally running service applications. Like WFEs, they don’t have the resources.
So where does user content go? Ladies and gentlemen, tonight (and every night) the role of database server will be played by Microsoft SQL Server!
That’s right, all that user content (and some other stuff, too), go into SQL Server databases – specifically ones called 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 minimum latency to perform optimally SharePoint to Work. For that reason, SharePoint is typically not installed on your database servers, which is fine because it doesn’t need to be. Your WFEs and application servers only need to know where the databases go, which you configure when installing SharePoint (or later).
SharePoint users never connect directly to the database server. They don’t need to since every request they make goes through the WFEs.
How Does SharePoint Work: Roles in Action
Now, if that’s all a little fuzzy, here are a few images to illustrate some logical server interactions for SharePoint to work. For the purpose of this post, these illustrations show separate servers. But remember, roles can be performed by a single server if need be (though that’s not recommended for production farms).
What About SharePoint Online?
Now, everything discussed above is for SharePoint Server (also called SharePoint on-premises or simply on-prem). So what about this SharePoint Online you keep hearing about?
SharePoint Online is a version of SharePoint hosted in the cloud by Microsoft as a service they offer in Office 365. What that means, in relation to this post, is you and your organization are not responsible for farm architecture – Microsoft is. You don’t need to take weeks defining performance requirements. Don’t need to worry about defining which server will perform which role(s) and then install SharePoint and load balance service applications. You don’t need to plan for scaling down the road. You tell Microsoft how many users you have, and you’re ready to go. What you still need to do is set up the information architecture, but what you do there is determined by how your organization is working with SharePoint. That’s a post for another day!
Now that we’ve answered some of your questions around “How does SharePoint work?” you may be wondering what you can do to manage it well. You’re not alone. It’s difficult to gain complete visibility and control of on-premises SharePoint deployments, and the stress of adding hybrid management to the mix can cause you to get lost pretty fast. Sign up for our definitive SURVIVAL GUIDE FOR SHAREPOINT to alleviate those fears and teach you how to not only SURVIVE, but THRIVE in the next era of SharePoint.