Tag: SharePoint Web Front-End

Application role in MinRole is also acting like front-end role

This post is not going to introduce what MinRole in SharePoint 2016 is. You are better to get it from massive number of articles written by SharePoint experts in the community. Personally MinRole is only helpful to those who are not familiar with designing and administering medium to large farm. When Microsoft says “Hey you only need to select the role this server is going to play!” then you feel like you are going to be an unoccupied SharePoint administrator perhaps because MinRole is your friend, giving you advise on compliance from the farm management perspective. The description made by Microsoft sounds so straightforward that SharePoint farm architect can just select without really understanding and planning their farms. There is not any article which deeply tells you how SharePoint processes each role in MinRole mode behind the scene.


Determine your Web Front-end server

Almost architecture design documentation I have had chances to review so far wrongly indicated actual number of web front-end servers in SharePoint farm. There are not many articles dedicated to telling you how to identify which servers performing web front-end role in an existing farm. They likely are written to let you know how many web front-end servers you should have for a good design and better performance.

This article is going to share you a very quick tip to determine a web front-end server. It will also provide a few caveats to help you maintain and mitigate potential risks.

What is so called a web front-end server?

A web front-end server basically is responsible for handling web services and hosting web applications and pages representing to end-users. It also receives incoming page request including query made in browser from end-user. To check to see whether a server in your farm is a web front-end or not, open Central Administration > System Settings > Manage services on server. In the Services on server page, select server and check Microsoft SharePoint Foundation Web Application service. If it’s started, the selected server is acting as a web front-end server.

You can also do a quick check through PowerShell.

If you see Online status, the service is started.

Caveats and Considerations

There are caveats and considerations on the topic you would have to be aware of. First, when documenting your SharePoint architecture, count any servers that have Microsoft SharePoint Foundation Web Application service started. For example, a farm that has totally 5 servers may have 3 web front-end servers, 2 application servers and 1 database server. It’s because one of the server that acts two roles: web front-end and application. Incorrect documenting would probably lead to wrong direction in SharePoint farm design in the feature when you need to scale out.

What will happen if you stop or restart Microsoft SharePoint Foundation Web Application service on any SharePoint servers? People simply think that restarting a SharePoint service doesn’t affect SharePoint or when it affects, things can get sorted out rapidly. That’s not really true. When you stop the Microsoft SharePoint Foundation Web Application service, SharePoint will understand that the farm is going to remove a web front-end server. The configuration database will then either update the topology again. There would be no problem at this point. However, when you start the service again, custom solutions will be automatically deployed to the new web frond-end server. If your solutions have user controls, SafeControl entries will be added to the web.config file. IIS settings are changed as well.

I recently involved in a disaster case in which the main web front-end MOSS 2007 server went down due to inadequate space for logging. I then stopped Windows SharePoint Services Web Application service in it to route all requests to the second web front-end server. Everything worked on the end-user side after then. The problem was that the Central Administration hosted in the main web front-end server was not accessible to us. When we started Windows SharePoint Services Web Application service again, all SharePoint sites we opened in the main server completely went down throwing out Unexpected error message – one of the provoking error messages Microsoft has ever made in the SharePoint platform. We spent hours investigating in SharePoint logs and realized that many controls were missing, IIS changes or so on. Making a copy of the second web front-end server’s IIS settings and web.config file didn’t work. Finally, we came to the decision to have to recover the main web front-end server entirely including system state. In a nutshell, if you restart Microsoft SharePoint Foundation Web Application service, be aware of the following things:

  • Custom solutions are deployed to the new web front-end. Resources including GAC files may overlap existing one.
  • Central Administration web site may not be accessible if it’s hosted in the server you stop the service.
  • Changes are made in the web.config file and IIS settings.

If you encounter that the Microsoft SharePoint Foundation Web Application service in SharePoint 2010/2013 is stuck on starting, chances are you have to run the following command:

This command can be applied for MOSS 2007 environment. In terms of third-party production deployment, the pricing may vary. Most common are based on the number of web front-end servers in farm. Saving the licensing cost by stopping Microsoft SharePoint Foundation Web Application service is not recommended.

When you are not enabling Microsoft SharePoint Foundation Web Application service, Health Analyzer warns you. Trust you design plan first, then Health Analyzer.

Last thing, impact on application server’s performance may exist if you start Microsoft SharePoint Foundation Web Application service in it. The worker process and timer service consume high memory while the application server needs resources to perform critical service applications (e.g. Search or Excel Service application).


Determining Web front-end role in your SharePoint farm is critical to your entire SharePoint solution. Upon the design, you can tune up SharePoint performance by enabling services in servers properly. Moreover, with correct determination, your web application and SharePoint sites are fully protected.

Do consider carefully planning for backup and recovery for your web front-end servers as they make SharePoint available to end-users who pay you money. Making them down means you lose buck and possibly dream job.

© 2018 The Soldier of Fortune.