SNAGHTMLf8ffd7d

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).

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. 

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. 

  1. Install Windows Server 2012 R2, .Net Framework 3.5 (note data drive)
  2. Enable Remoting (if using remote install)
  3. Install and Configure SQL Server 2012 or 2014
  4. Create Service Accounts in AD
  5. Grant Service Account permissions for install
  6. Configure the install source
  7. Create AutoSPInstaller answer file
  8. Test SQL connection (optional)
    1. 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:

  1. 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!
  2. imageYou 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
    1. 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:

  1. Enable through GPO
    1. Go to start –> run –> gpedit.msc, then go to Computer Config –> Admin Templates –> Windows Components –> Windows Remote Management –> WinRm Service
    2. Set “Allow CredSSP authentication = Enabled
    3. Set “Disallow Negotiate authentication” = Disabled
    4. Set “Disallow Kerberos authentication” = Disabled
    5. Set “Allow remote server management through WinRM” = Enabled, and in the box for IPv4 filter, type *
    6. Close out of gpedit

      image



  2. From a PowerShell prompt, type “Get-Service WinRM” (without quotes).  Ensure that the Status is Running
  3. In the same PowerShell window, type winrm quickconfig.  It should say WinRM is already running, and is already set up for remote mgmt.

    SNAGHTMLfcf99ab



  4. Back on the App server, from a PowerShell prompt, type “Test-WSMan <remote computer name>” (without quotes).  It should return something like this:

    SNAGHTMLfd44151

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:

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

    image



  • 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

      image



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!