If you’ve ever installed SharePoint before (and especially 2013), you know what a joyous amount of fun it is to do it all by hand. If you had a bit more experience, then you knew you could (and did) use PowerShell to automate your farm configuration and subsequent service applications, etc. This was and still is fine, and your preferred method is completely up to you. But there is another option to consider – autospinstaller. I love this thing, it has to be one of my most favorite and well-written free tools around. I don’t know exactly when it was born, but the earliest changesets I see on codeplex are from July/Aug 2010 so a little after SharePoint 2010 went RTM. It’s constantly being updated to support the ever-changing patch model of SharePoint, and incorporates fixes and feedback from the vast number of folks using it.
In this 2-part series I am going to take you through all of the necessary steps to use autospinstaller to build a 3 server farm doing remote installations on Windows Server 2012 R2 with SharePoint 2013 recent CU. When I say all, I am referring to the SharePoint relevant pieces and the autospinstaller. I will not walk you through installing Active Directory, Windows Server or SQL server. There are plenty of blogs that do that already. There are a few caveats that aren’t fully covered by the information and other steps out there. Continue reading for SharePoint 2013 installation nirvana (provided you follow all provided instructions with the tool as well).
Part 1 (this post)
Part 2
Our Goal
The end result after performing these steps will be the following:
Use Windows Server 2012 R2 and at least SQL Server 2012
Install SharePoint 2013 in a 3-server farm with slipstreamed SP1 plus the May 2015 CU, splitting services across the servers:
App Server
Web Front End (WFE)
Search Server
Desired Farm Services Split
Here’s how I broke out the services between the farm servers in this 3-tier topology with 4 servers:
Server Role
Service
App Server
Access Services
App Mgmt
Application Registry
BDC
Excel calculation
Machine Translation
Managed Metadata
SP Foundation Subscription
PerformancePoint
PowerPoint Conversion
Secure Store
User Profile / UPA Sync
Visio graphics
Word Automation
Work Mgmt
Central Admin
Document conversions
*Claims to Windows Token
*Distributed cache (no)
*SP incoming email
*SP Foundation Sandboxed code
*Request Management
Search Admin Component
Workflow Manager
WFE
*Claims to Windows Token
*Distributed cache
*SP incoming email
*SP Foundation Sandboxed code
*Request Management
SP Foundation web application
SP Foundation Workflow Timer
Search query processing
Search Index component
Workflow client
Search
Lotus Notes connector (Search)
Search Admin Component
Search Crawl component
Search Content Processing
Search Analytics processing
SQL
Database
It’s generally recommended to at least have the Distributed Cache on the WFE, but you can have it on more than that server if desired, however it requires additional configuration. The items with an * denote services listed in the Farm Services section in the AutoSPInstaller online tool.
Desired Search Topology
Our search topology will look like this:
Admin Component
Crawl Component
Query Component
Content Processing
Index partition
Analytics Processing
App
X
WFE
X
X
Search
X
X
X
X
The core thing is that the Index and Query components should be together, and are generally on the WFE. The other services can go on the App server or Search server or both, depending on your desired redundancy and load sharing.
What You’ll Need
Here is a list of the software needed to get everything done.
AutoSPInstaller
PSExec (if you don’t have internet access)
AutoSPSourceBuilder
See note below
AutoSPInstaller Online
Windows Server 2012 R2
SQL Server 2012 / 2014
SharePoint 2013 SP1 + May 2015 or newer CU
.Net Framework 3.5!!
AD Service Accounts
How AutoSPInstaller Works
It’s magic! Well no, it’s a ton of PowerShell awesomeness! I just wanted to call it out a few points to be aware of, mostly when you are installing in a remote server scenario. First a quick review of what it does complete. AutoSPInstaller completely automates the whole install of SharePoint from:
Validate all service accounts and passwords specified
The installation of SharePoint from installing the pre-requisities and configuring server roles
Installing the SharePoint files
Applying the latest update / CU
Creating a new server farm or joining the server to an existing farm
Create managed accounts
Creating and configuring service applications, including the User Profile Service, and Search where you can split the search roles up to different servers
Creating any specified web applications, by default a Portal and My Sites
Install Project Server (if specified)
Other little configurations like editing local HOSTS file and other stuff
Remote Installations
All that is great and becomes more powerful when you use the Remote Install option to install multiple servers. It does this via PowerShell Remoting and Windows Remote Management (WinRM). This needs to be configured before running the installation, and I will give you the steps below. Here are a couple things to note when doing remote installations:
When the remote install option is checked, the way it performs the install is that it runs and goes through the ENTIRE script install on the local server before moving to the remote server. It runs remote PowerShell on the other servers to go through the entire install on that server.
The script will NOT copy the binaries / install directory to the remote servers. You either need to copy the install directory to the same path on the remote servers, or start the script from a UNC path so the other servers can access it.
If the Parallel install option is checked, the install will fully complete on the local server first as above, and then proceeds to the remote servers all at once instead of one at a time. If there is only 1 remote server, checking parallel install will have no effect
Preparing for the Install – Part 1
Here are the high level steps that are needed before we can actually start the installation of SharePoint with AutoSPInstaller.
Install Windows Server 2012 R2, .Net Framework 3.5 (note data drive)
Enable Remoting (if using remote install)
Install and Configure SQL Server 2012 or 2014
Create Service Accounts in AD
Grant Service Account permissions for install
Configure the install source
Create AutoSPInstaller answer file
Test SQL connection (optional)
if using named instances, I like to pre-create SQL alias, and be sure to leave auto detect checked since port isn’t 1433
Let’s go through these one by one.
Install Windows Server 2012 R2
Why not use the latest? It’s likely what you get when you go to download ISOs from the Volume License center. Install the OS but DON’T install any patches yet. The big thing I want to mention here are two things:
When you create your drive configuration, it’s best practice to have a data drive that’s default for SharePoint data and a search index. Just make sure all SharePoint servers have the same drive letter mapping!
You will need the .Net Framework 3.5 which is not installed by default in Server 2012 R2. You have to use Server Manager and install the feature, and this must be done so that certain KB hotfixes are installed. You can find detailed steps on TechNet
NOTE - If you don’t do this, the SharePoint prereqinstaller will fail to configure the IIS role and services with gnarly errors.
Once that is done, install all patches until you can’t patch anymore.
Enable Remoting (if using remote install)
If you are doing remote installs for a multi-server farm configuration, we need to enable the servers to be administered remotely. You can do this differently, but I like this method of using Group Policy. Perform the following steps to enable the ability to do PowerShell remoting and configuring WinRM:
Enable through GPO
Go to start –> run –> gpedit.msc, then go to Computer Config –> Admin Templates –> Windows Components –> Windows Remote Management –> WinRm Service
Set “Allow CredSSP authentication = Enabled
Set “Disallow Negotiate authentication” = Disabled
Set “Disallow Kerberos authentication” = Disabled
Set “Allow remote server management through WinRM” = Enabled, and in the box for IPv4 filter, type *
Close out of gpedit
From a PowerShell prompt, type “Get-Service WinRM” (without quotes). Ensure that the Status is Running.
In the same PowerShell window, type winrm quickconfig. It should say WinRM is already running, and is already set up for remote mgmt.
Back on the App server, from a PowerShell prompt, type “Test-WSMan <remote computer name>” (without quotes). It should return something like this:
If it does, you should be good to go. Repeat the same procedure on all other remote servers.
Install and Configure SQL Server 2012 or 2014
I also will not bore you with the play by play of installing SQL Server. I will just say that it should be configured per best practice and properly optimized for SharePoint 2013. A great resource and reference for this is by SharePoint MVP Vlad Catrinescu entitled Maximizing SQL 2012 Performance for SharePoint 2013. It’s a great read and covers all the guidance needed about configuring SQL, splitting up the drives and post configuration and optimization. Be sure to set the MAXDOP setting, otherwise SharePoint won’t install. It was recommended for 2010, and now is required for 2013.
I should also mention that Todd Klindt has a nice 3-part blog series on sharepointpromag.com on this subject. He shows you how to save yourself some time and automate the post config as well.
Create Service Accounts in AD and Grant Access Permissions
Service accounts can vary widely, and opinions differ depending on who you ask ranging from 2 accounts to 15 accounts for full least privilege (give or take). I like to fall in the middle, but its up to you. Here’s a couple of resources to review to help you decide:
Blog from SharePoint MVP Vlad Catrunescu on the subject
Blog from SharePoint guru and all-around genius Todd Klindt
Plan for administrative and service accounts in SharePoint 2013 (TechNet)
Once you decide on the accounts, get them created in AD. The only one that’s really special is the user profile AD connection account. It needs replicate directory changes for the domain. Be sure to check the other gotchas around that depending on your domain name.
Now that you have them all created, be sure to grant them the necessary permissions. The install account needs to be a local admin on the SharePoint and SQL servers (or dbcreator and securityadmin in SQL), and the farm account on the SharePoint servers during install. You get the picture, but the above links give you all that info.
Configure the Install Source
Now we’re getting down to business. Go out and download AutoSPInstaller from Codeplex to the main App server and extract all the goodies. What we need to do is build the source directory. This is where things get a little confusing depending on what patches you’re installing.
Previously, you would manually slipstream your service pack and updates into the SharePoint install directory by extracting and copying into the \Updates folder. This is where you could use the AutoSPSourceBuilder and it would generate a combined proper service pack and CU source for you. You can’t do that anymore, and don’t need the source builder. On top of that, the SharePoint 2013 ISO that is slipstreamed with SP1 had a schema change where post-SP1 cumulative updates didn’t see the slipstreamed SP1 as the SP1 you needed. You had to re-download SP1 and overwrite the files or re-apply SP1 over top, THEN you could patch. UGH!
Well Microsoft has fixed this starting with the MAY 2015 CU. With this CU, you don’t have to redo anything with SP1 and can just install the CU. You can read more here. Here’s what you need to do now:
Download the SharePoint 2013 with SP1 ISO and mount to the root App server
Extract the AutoSPInstaller zip to C:\autospinstaller
Copy the contents of the SharePoint 2013 with SP1 ISO to C:\autospinstaller\SP\2013\SharePoint folder
Download the May 2015 CU or later, and copy (DO NOT EXTRACT) all 3 files to C:\autospinstaller\SP\2013\Updates. The August 2015 CU is out as of this writing, but I’m sticking with May 2015 for now. There will be 3 files, a long .exe and 2 .CAB files and AutoSPInstaller will install this patch manually instead of SharePoint setup
NOTE – If you are installing Project Server as well, be sure to get the version that includes Project Server updates
Now that we have our install source ready to go, we need to build our answer file for the scripted installation. I think we’ll save that and the actual install for part 2. Thanks for reading this far, and I hope this helps to navigate the confusing task that is installing SharePoint. Let us know how we can help you install SharePoint 2013 and contact us!