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).
The end result after performing these steps will be the following:
Here’s how I broke out the services between the farm servers in this 3-tier topology with 4 servers:
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.
Our search topology will look like this:
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.
Here is a list of the software needed to get everything done.
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:
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:
Here are the high level steps that are needed before we can actually start the installation of SharePoint with AutoSPInstaller.
Let’s go through these one by one.
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:
Once that is done, install all patches until you can’t patch anymore.
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:
If it does, you should be good to go. Repeat the same procedure on all other remote servers.
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.
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:
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.
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:
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!
The complementary paper includes over 12 years of research, recent survey results, and CRM turnaround success stories.
This 60-second assessment is designed to evaluate your organization's collaboration readiness.
Learn how you rank compared to organizations typically in years 1 to 5 of implementation - and which areas to focus on to improve.
This is a sandbox solution which can be activated per site collection to allow you to easily collect feedback from users into a custom Feedback list.
Whether you are upgrading to SharePoint Online, 2010, 2013 or the latest 2016, this checklist contains everything you need to know for a successful transition.