Setting up your SharePoint 2013 environment At Work – Part 6

I have got some positive feedback as of the 5th article regarding the very heinous error of missing .NET Framework 3.5 if people are using Windows Server 2012. Throughout the series, you have seen several issues caused by missing.NET Framework 3.5, such as SQL Server 2012 installation, SharePoint Preparation process. We hope the next release of Windows Server 2012 perhaps the edition of R2 will automatically install .NET Framework 3.5 in somewhere so we won’t get something rarely occurring in the life.

In the previous article, you are first introduced a few changes in SharePoint 2013 licensing model. Unlike SharePoint 2010, Microsoft no longer charges you external license in SharePoint 2013; internal license is the only you have to pay. Even more, the price of single SharePoint Server 2013 license is much cheaper than the SharePoint Server 2010. This model is good for deployments that have less than 400 active users. If you have a higher number, the licensing cost is actually higher than the SharePoint 2010’s. Next, you got your hands dirty on SharePoint Server 2013 installation along with some recommendations. The thing to note is that the setup account you may have read in Microsoft TechNet guidance is indeed the FARM ACCOUNT.

If you are following this series, your environment completely has the two-server SharePoint farm deployment. One is database server that hosts all SharePoint databases by default. Another one is the application server that intentionally hosts services and Central Administration web application. In this article, we will join a new server playing the web server role to the existing SharePoint farm. In previous articles, we started with some principles and fundamentality before configuration but in this article, configuration is first covered.

The figure below depicts the 3-tier farm you are going to build. The APP2 machine is going to be joined to the existing SharePoint farm that currently has two machines: APP and DATABASE. The APP machine now is not only playing as an application server but a web server that hosts Central Administration web application. Ideally, we will move it to the new APP2 machine as planned.

On the new machine, you still need to install SharePoint Server 2013. That said, one more license needs to be purchased so your pocket is going to be tattered. Make sure you install .NET Framework 3.5 first unless the preparation installer can’t complete its tasks. Install SharePoint Server 2013 until you are on the Running Configuration Wizard page. Select Run the SharePoint Products Configuration Wizard to start configuring the new server to join the existing farm. Again, click the button that has stupid name Close.

Before joining, some services in the server need to be stopped or started. On the Connect to a server farm page, select Connect to an existing server farm.

On the Specify Configuration Database Settings page, enter the database server and your instance if you are not using default instance name. If you are using SQL Alias, you are still be able to use this typical name structure. Note again, SQL Server Browser service must be starting and the machine is able to communicate with the database server. Click Retrieve Database Names to query all existing farm configuration databases the selected database server is storing. In this case, I only have one SharePoint farm stored in SharePoint_Config database.

On the Specify Farm Security Settings page, enter the passphrase we discussed in the previous article. This kind of password is used each time you need to join new whether web or application servers to the existing farm. If you do forget this password, fortunately Microsoft SharePoint allows you to reset it by running PowerShell script under Farm account privilege. Opening SharePoint 2013 Management Shell and use the following script:

[powershell]$p = convertTo-secureString –string “your passphrase” –asPlainText –Force
Set-SPpassPhrase –passPhrase $p –Confirm[/powershell]

Confirm your passphrase again and enter Y(yes) to update the new passphrase. The account used to reset passphrase must have rights on farm configuration database.

On the Completing the SharePoint Products Configuration Wizard page, select Advanced Settings. On the Advanced Settings page, select Use this machine to host the website option. In this case, we are going to use the APP2 machine to host Central Administration web application. That said, the machine APP is no longer responsible for serving for the Central Administration web application.

Review settings that are going to be applied and wait on the configuration process. After complete, you will see that the new URL of Central Administration has changed. Previously, the that URL was http://app:9999 but after joining and changing the configuration, now the URL is http://app2:9999/. Obviously the APP2 machine – a newly joined server farm is hosting the Central Administration web application.

Now you have done adding the machine APP2 to the SharePoint farm. Open IIS Manager on the two machines and notice that even SharePoint Central Administration v4 exists on both but you just see the Central Administration application pool in IIS Manager on the machine APP2 that is configured to host the Central Administration web application.

If you want to see how many servers involving in your SharePoint farm, open Central Administration website, navigate to System Settings > Manage servers in this farm. In there you should see at least a database server that has the Microsoft SharePoint Foundation Database running, and your application server and web server.

What is so-called SharePoint Web Front-end server?

Microsoft describes that a Web front-end server is responsible for handling all requests of SharePoint web pages coming from an end-user when he opens SharePoint site. The request includes image, content, CSS files, web service…etc presenting to the end-users on client computers. It is abbreviated WFE in Microsoft technical documentations. Think of an example, when someone types his keyword in the Search box on the content publishing SharePoint site, the query service running on the Web front-end server will be triggered to communicate with the application server where Search service application is running, then the query component will get in indexed database to query what the end-user needs to find. Finally, the result will return to him through the web front-end server. I’m not, of course, going deep into how Search works. I’m just explaining sort of what the web front-end server is doing in SharePoint context.

When designing SharePoint physical architecture combining with logical architecture, many people are still confused as to what is exactly positioned as a web front-end server. I’ve also got many questions as to where to find any clue that states that a machine is running as a web front-end server. As you can see, when you complete installing and configuring SharePoint farm by default, there are 5 services running.

  • Central Administration
  • Distributed Cache
  • Microsoft SharePoint Foundation Incoming E-Mail
  • Microsoft SharePoint Foundation Web Application
  • Microsoft SharePoint Workflow Timer Service

Each of them has its own different responsibility. Let’s say you don’t know all of what those services are running for. You know, however, at least one of them must be running to handle request if someone opens a SharePoint site. Predictably it’s Microsoft SharePoint Foundation Web Application. Back to my SharePoint farm that has APP and APP2 machines running the 5 services mentioned above by default. To check to see if Microsoft SharePoint Foundation Web Application has direct impaction on the SharePoint website, I’ve purposely created two site collection running under two newly created web applications on relative machines with different URLs (http://app:29483 and http://app2:43354). Now what I want to do is stop the Microsoft SharePoint Foundation Web Application on the APP machine and see how it goes. To do this, I use the following PowerShell:

[powershell]$a = “app”
Get-SPServiceInstance –Server $a | where-object {$_.TypeName –eq “Microsoft SharePoint Foundation Web Application”} | Stop-SPServiceInstance [/powershell]

After that, try to open the URL http://app:29483 and it’s unavailable. Continue stopping the Microsoft SharePoint Foundation Web Application service on the APP2 machine then open the URL http://app2:43354, it’s unavailable too. It takes a little time to stop if you are having several web applications. Don’t be anxious if you see it’s stuck at Stopping. You just need to wait until it’s completely disabled. Now start the service on the APP machine using the following PowerShell.

[powershell]$a = “app”
Get-SPServiceInstance –Server $a | where-object {$_.TypeName –eq “Microsoft SharePoint Foundation Web Application”} | Start-SPServiceInstance [/powershell]

After the execution of this PowerShell, the http://app:29483 is up shortly like a charm but the http://app2:43354 is still unavailable.

Through this experiment, you can see that if the Microsoft SharePoint Foundation Web Application service is not running on any machines, the relative SharePoint site is stopped. It’s because there is nothing to process the request when we open SharePoint site. This leads to the unavailability of the site. There is absolutely no magic here.

Come to conclude that a machine in which the Microsoft SharePoint Foundation Web Application server is running is called web front-end server.  Don’t confuse with Central Administration service that runs at the back-end server. Even if you stop it, the Central Administration website is unavailable.

In terms of performance, people recommends turning off Microsoft SharePoint Foundation Web Application service to reduce workload of IIS worker processors. However, note that if you want to deploy solution packages (WSP) to all machines in the same farm from a central location (e.g. the machine that runs Central Administration service), you have to turn on Microsoft SharePoint Foundation Web Application service on each machine. It’s because in some cases you need SharePoint DLL files to be deployed to GAC on all machines.

The article gives you quite enough as to what you need to know about building a multi-server farm. It also covers very common concept of web front-end server role in SharePoint topology. Now you are done setting up a multi-server farm with several recommended best practices. In fact, you can install all in one but that’s not what we are aiming to. One of the reasons is that sometimes you want to see differences between single server and multi-server farm when deploying SharePoint solutions or Apps.

What should the next article of this series cover?

Stay tuned!


  1. January 10, 2016 — 1:10 pm

    Hi Thuan,

    Best article related to setting up multi-farm SharePoint. I have three small concerns. At least answer the first one please, as I’m quite curious to know about this 🙂 rest you can ignore.

    1. If I add another WFE, I need to host site there as well, will it make CA available from there? Even that page from where you make this hosting says CA should only be hosted on App server. This is very confusing….
    2. I still see SharePoint Central Administration v4 applicaiton pool on both server (App and WFE). App was first created then WFE added.
    3. While adding WFE I saw the URL for CA got changed. But whenever I open CA I see the old URL.

    • nnthuan
      January 13, 2016 — 3:00 am

      Hi Kasjifnizam,

      Please see my answer below
      1. During the configuration of joining a new server to the existing farm, you are to have chance to configure to run Central Administration service on the new server. You may need to have a look at this article
      2 and 3: If you start Central Administration service on another server and stop on the existing one, you need to go to Alternative Access Mapping to change the URL manually. SharePoint is not smart enough to cater that for your.

      Kindly let me know if my answers address your concern.

  2. March 8, 2016 — 7:53 am

    Hi Thuan,

    Sorry I couldn’t get back earlier.

    Thanks for clearing my confusion. Your blog really helped me understand all this SharePoint architecture.

    Thanks again!

  3. Khaled
    April 6, 2016 — 11:37 am

    Just finished reading and I’m a total newbie in SharePoint world.

    This is the best article I’ve read so far during my daily search. Exceptionally well written with great details.

    Thank you for your help, please continue writing about anything, wonderful style of writing you have.

    • nnthuan
      April 7, 2016 — 10:26 am

      Thank you very much Khaled. Glad you like my article. Please let me know if you have something to ask me to write.

  4. Khoa
    June 8, 2016 — 1:03 pm

    Hi Thuan,

    Many thanks for your useful article. My farm is as follows: 2 ADs, 1 WFE/APP, 2 DBs. I already added one more WFE/APP into the existing farm. Everything works well but the Search topo doesn’t include the newly joined WFE/App. So, I’d like to configure Search on the new WFE/App for load balancing.

    Please let me know the way of doing this


  5. Ted
    November 23, 2016 — 2:50 am

    Hey Thuan I have a question I have 1 wfe, 1 app, 1 db server. The wfe server has IIS,CA, and Foundation Web Service on. The App server has IIS, and central admin, but doesn’t have Foundation Web Service turn on. Should I just uninstall iis and central admin on the app server? The reason I’m asking is because my OOTB workflows are showing not started status and I feel like my workflows are trying to hit my app server instead of my wfe.

    • Thuan Soldier
      November 25, 2016 — 11:02 am

      Hi Ted,

      If you workflow has custom timer job written to Timer Job in Central Administration you must start Central Admin service on the same server where Foundation Web Application service is started. Please read my post here for more information IIS must stay intact in every server where SharePoint server is installed.

Leave a Reply

© 2018 The Soldier of Fortune.