Update! This blog post is dated, check out https://sysadminblogger.wordpress.com/2018/05/24/installing-and-configuring-sharepoint-2016-on-prem-with-a-combination-of-powershell-and-configuration-wizards/ instead.
I got the task of installing SharePoint 2013 for a small business. The SharePoint site won’t be used by that many people simultaneously, so the server load will remain quite small. With that in mind I had to figure out a suitable topology. There are many, many sources on the web describing this, so getting information wasn’t a problem. In the end, I decided to go with a two-tier topology. A single-tier would have been sufficient, but It’s nice to have a separate SQL-server which can be used by other applications/servers as well.
“In a two-tier deployment, SharePoint 2013 components and the database are installed on separate servers. This kind of deployment maps to what is called a small farm. The front-end Web servers are on the first tier and the database server is located on the second tier. In the computer industry, the first tier is known as the Web tier. The database server is known as the database tier or database back-end”.
Another useful link:
https://technet.microsoft.com/en-us/library/cc263199.aspx (you’ll find a nice document/pdf describing Streamlined Topologies for SharePoint 2013). The document states that a two-tier farm is sufficient for up to 10.000 users. More than enough in my case.
My installation is actually based on https://captainofsharepoint.wordpress.com/2013/02/27/the-art-of-installing-sharepoint-2013-in-a-3-tier-topology-part-one/, even though I would call this a two-tier topology and not three. The SQL-guide from this post is not used, as it suggest installing every component (which is unnecessary). Shortly said there are only two servers included in my setup, namely:
- SharePoint 2013 (more about features and roles later in the document)
- SQL Server 2014 Standard
I won’t go into the hardware details of the servers themselves because it varies so much from deployment to deployment. It’s easy to scale out with more memory or better/faster SAN-disks if you have the need for it in the near future. It’s also a good idea to read the following information before installing: http://sharepointpromag.com/sharepoint-2010/top-10-sharepoint-2010-configuration-mistakes-and-how-fix-them
AD Accounts for SharePoint and SQL
My first task was to create the needed service accounts in Active Directory. There’s a very good site describing the needed accounts at http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=391. I only used
- sp_install (SharePoint installation)
- sp_farm (SharePoint Farm Account)
- sql_install (SQL server installation account)
- sql_user (SQL user account)
from the list. Later I created an account named sp_srv for running miscellaneous services. This is more than plenty for such a small deployment. You can read more about service accounts here:
SharePoint 2013 Service Accounts Best Practices Explained:
http://absolute-sharepoint.com/2013/01/sharepoint-2013-service-accounts-best-practices-explained.html (I’m using medium security option)
Initial deployment administrative and service accounts in SharePoint 2013:
SharePoint 2013: Service Accounts:
SQL Server 2014
Next on the checklist was the installation of SQL Server 2014. SQL is a requirement for SharePoint so it should be installed before you install SharePoint itself. I decided to go with http://sharepointpromag.com/sql-server-2012/sql-server-2012-sharepoint-2013-database-server-setup as a base for my installation. Before installing, I also suggest reading the following (you can never be too prepared):
A simple install of SQL Server 2012 for SharePoint Server 2013 or 2010:
Instruction Guide for Installing SQL Server 2012 SP1 for SharePoint 2013:
Install SharePoint 2013 – Part 4 SQL Server:
Service Account Suggestions for SharePoint 2013:
“The SQL Guy” Post #15: Best Practices For Using SQL Server Service Accounts:
After doing some homework (reading articles) I came up with the idea of using SQL with a Named Instance (with SQL-aliases for SharePoint) instead of the Default Instance. I also thought of blocking the default SQL port and using a new static one (configured by SQL aliases). All of this to get better security. I buried this idea however, and instead running with the Default Instance following this guide: http://blogs.technet.com/b/rycampbe/archive/2013/10/14/securing-sharepoint-harden-sql-server-in-sharepoint-environments.aspx. (The server itself is already quite well firewalled by a hardware firewall). Some more information regarding the same matter:
Best practices for SQL Server in a SharePoint Server farm:
Blocking the standard SQL Server ports:
Configure SQL Server security for SharePoint 2013 environments:
If one ever decide to use SQL aliases, it’s advisable to read the following document: http://blogs.msdn.com/b/sowmyancs/archive/2012/08/06/install-amp-configure-sharepoint-2013-with-sql-client-alias.aspx
I secured the SQL server using “server isolation” instead.
“Server Isolation can be done several different ways, but the end result is the same: configuring the server to only respond to authorized machines.”
In my environment, I’m only allowing traffic from the soon-to-be installed SharePoint server (using the above method).
With the security taken care of, it’s finally time for installation! Following the guide I mentioned earlier (http://sharepointpromag.com/sql-server-2012/sql-server-2012-sharepoint-2013-database-server-setup), I went through the steps. I got a firewall warning in the setup (Fig 1), but it was easily fixed by poking a hole in the windows firewall (Fig 2).
Fig 1. SQL Server 2014 Setup warning
Fig 2. Poking a hole in the firewall (Added the SharePoint server IP).
- Enabled Server Feature: .NET Framework 3.5 (needed for SQL server installation)
Continued the setup:
- SQL Server Feature selection:
- Database Engine Services
- Management Tools – Complete
- That’s it, no extra crap;
“After selecting SQL Server Feature Installation and clicking Next, a list of SQL Server features is displayed, as shown in Figure X. We really need only one SQL Server feature for SharePoint: Database Engine Services. However, I will also install the Management Tools (Complete) feature, which gives you handy tools such as SQL Server Management Studio. As you browse through the list of features, you might be tempted to check more features than you really need. But unless you’re going to use a particular feature immediately, I don’t recommend installing it. If you want to add a feature later, such as SQL Server Reporting Services, you can just run Setup again and add the feature to your existing instance.”
Server Configuration/Service Accounts:
- SQL Server Agent and SQL Server Database Engine: sql_user (the AD account created earlier).
Database Engine Configuration/Specify SQL Server Administrators:
- myadminaccount and sql_install (the AD account created earlier).
I’m using the default installation paths for SQL as this is a small scale installation.
All tweaks are based on the following articles:
- Max degree of parallelism = 1
- Maximum server memory 3.5GB (out of 4GB)
- Model Database’s Recovery Model: simple
- Compressed backups
- Also adding the sp_install user to SQL, see below:
“To give the sp_install account the permissions it needs, in SSMS navigate to Security, Logins in Object Explorer. Right-click and select New Login. Under General, type the username and make sure you include the domain. Then on the Server Roles page, shown in Figure 3, select the dbcreator and securityadmin check boxes and verify that the public check box is still selected. Then click OK.”
Fig 3. Assigning Permissions to the sp_install Account
“Let me offer a few words of advice about setting the sp_install permissions. SharePoint assumes that those three roles, dbcreator, public, and securityadmin, have the default set of permissions in SQL Server. Don’t alter those permissions. I’ve seen DBAs in very secure environments try to lock down these three roles. Doing so will most certainly break SharePoint in crazy and unusual ways. That might not happen right away, and it might not happen to you when you’re using the interface. It could be a monthly timer job that fails, for instance. Also, don’t change any SQL Server permissions that SharePoint sets. SharePoint is very fussy, and if it sets permissions, it really needs them. Because of SharePoint’s rigidity on its SQL Server permissions, I recommend that you put SharePoint in its own SQL Server instance. SharePoint will thank you, and so will your DBAs.”
That’s it for SQL, moving on to the SharePoint installation.
SharePoint Server 2013 installation
I’m being a bit lazy now and just copy/pasting information… why rewrite something that someone has already written (well)?
SharePoint Server 2013 checklist:
Before you begin to install and configure SharePoint 2013, do the following:
- Ensure that you are familiar with the operating-system guidelines described in Performance Tuning Guidelines for Windows Server 2008 and Performance Tuning Guidelines for Windows Server 2008 R2.
- Ensure that you have met all hardware and software requirements. You must have a 64-bit version of Windows Server 2008 R2 SP1. For server farms, you must also have a 64-bit version of SQL Server 2008 R2 SP1. For more information about these requirements, such as specific updates that you must install, see Hardware and software requirements for SharePoint 2013
- Ensure that you perform a clean installation of SharePoint 2013.
- Ensure that you are prepared to set up the required accounts by using appropriate permissions. For detailed information, see Initial deployment administrative and service accounts in SharePoint 2013
- Ensure the Max degree of parallelism is set to 1. For additional information about max degree of parallelism see, Configure the max degree of parallelism Server Configuration Optionand Degree of Parallelism
Everything in order, let’s continue! (Again, the installation is quite much based on https://captainofsharepoint.wordpress.com/2013/02/27/the-art-of-installing-sharepoint-2013-in-a-3-tier-topology-part-one/)
Well, I didn’t get so far. The prerequisite checker failed with the message: Application Server Role, Web Server (IIS) Role: configuration error.
A suggested solution was to install a hotfix from Microsoft; https://support.microsoft.com/en-us/kb/2765260. This didn’t work however, as the fix was only for Windows Server 2012, NOT the R2 version. Next test was to follow a guide from http://blogs.msdn.com/b/fabdulwahab/archive/2013/08/29/sharepoint-2013-installation-and-configuration-issues.aspx:
Steps to fix (Installing .Net Framework 3.5):
- Insert the Windows Server 2012 installation image or DVD
- Open a command prompt window (run as Administrator) and run the following:
- Dism /online /enable-feature /featurename:NetFX3 /All /Source:D:\sources\SxS /LimitAccess
Fig 4. Success! 🙂
Continuing with the setup…
Fig 5. Complete installation (production). Using default file locations (because small scale installation).
Done. The SharePoint Configuration Wizard will then run:
Fig 6. Create a new farm
Fig 7. Database settings. Database server and account settings were discussed in the SQL chapter.
Fig 8. SharePoint Central Administration Web Application
Port 18811 (or whatever SharePoint chooses for you) must be blocked (outside the domain), otherwise the Central Administration URL will be open for anyone on the Internet.
Fig 9. Completing the configuration wizard
Fig 10. Configuration successful!
There are A LOT of different services running on a SharePoint server. However, in a small scale environment, you’ll probably only need/use a few of these. I took a look at the old server and compared the services running there. Here’s a screenshot of SharePoint 2010 and its active services:
Fig 11. SharePoint 2010 services
From the screenshot we can see that the following services are running:
- Central Administration
- SharePoint Foundation incoming E-Mail
- SharePoint Foundation Web Application
- SharePoint Foundation Workflow Timer Service
With this in mind, I tried to keep the services at a minimum on the SharePoint 2013 server as well.
I couldn’t find the exact same ones in 2013, but I decided to go with the following:
Fig 12. SharePoint 2013 services
- Search Service Application
- State Service
- Usage and Health data collection
After SharePoint had configured itself I was greeted with a message that some services are running with the “wrong” accounts (Fig 13).
Fig 13. SharePoint Failing Services
The failing services are:
- SharePoint Central Administration v4 (Application Pool)
- SPTimerV4(Windows Service) = Farm
- AppFabricCachingService (Windows Service)
My idea was to run the default SharePoint services with the “sp_farm” account. Other services can be run with the “sp_srv” account if/when needed.
Update: It’s not recommended running the Wizard, instead you should manually configure the settings.
You change the account settings in SharePoint –> Central Administration –> Configure service accounts. I changed the farm account to “sp_farm”. Everything more or less broke after that 😦 I had to do some googling to get it up running again.
Solution (before changing farm account to sp_farm):
- Register the account (sp_farm) as a managed account. To change a managed account password go to Central Admin > Security > Configure Managed Accounts (/_admin/MangedAccounts.aspx). Click the Edit icon next to the account whose password you want to change.
Fig 14. Register Managed Account.
- Go to the Configure Service Accounts page and Select the Farm Account and set the new managed account
- Reboot the server.
Done. SharePoint is now installed 🙂
You shouldn’t use http with SharePoint outside your domain. Instead you should use https (http over SSL). Request a certificate for your SharePoint site from a 3rd party certificate issuer (or similar), and then apply the certificate. You could/should also use http redirection (http –> https) and/or Alternate Access Mappings. You can follow these guides for example: