Welcome back to part 2 of my short series of using AutoSPInstaller to build a 3-tier multiple server SharePoint farm.  Last time we looked at all of the work we needed to do to get setup and discussed what our end goal was.  Now we can get down to business and start some installation!   I’ll walk you through the most critical part – creating your answer file, then the installation itself.

• Part 1
• Part 2 (this post)

Preparing for the Install – Part 2

As you read in part 1, we did all the work to get the OS and SQL installed, then prepped the SharePoint servers for install.  Now all we need to do is create our answer file.  The answer file is an XML file that provides all of the necessary input to the automated installation, where you define all your server and database names, services, roles, usernames, etc. 

Create an answer file

This used to be rather painful because it involved reading a long XML file, and it was easy to mess up and prone to miss a password, or ensure everything lined up.  Then someone wrote a GUI-based local application where you would fill out a form and it would spit out the XML file.  That was awesome, and now it’s even better as it’s been turned into a web tool!  Go to http://www.autospinstaller.com, and click Build a Farm.  It presents rather intelligent forms where you fill out the relevant information, then it spits out the XML answer file which you just copy and paste into a local file.  You can also load in previous XML answer files if you need to make some changes to existing files.

For our farm, we’re building APP, WFE and Search servers.  Let’s get configuring:

• On the site, choose Build a farm, then start from template
• Start down the pages in order.  Start by adding your 3 servers on the Servers tab
• Install tab
  • Give it a name like TEST, PROD or similar.  This text will be added to the SharePoint Suitebar text on the Central Admin site
  • Choose 2013
  • Choose Remote install, and parallel if you like (remember parallel only works for the remote servers after the 1st server is fully complete)
  • I suggest choosing Auto logon, as the prereq installer makes you reboot multiple times
  • Leave all the Disable components checked
  • For the Data directory, it’s best practice to put this on a secondary drive, like D:\SearchIndex
  • Choose your SKU of SharePoint and enter your product key
• Farm tab
  • Most of this is fairly self-explanatory
  • For the DB server, be sure to use your SQL alias and not the actual server name
  • Choose a DB prefix – this will prefix all of the database names, I suggest something just like SP_, and not version specific 
  • For Central Admin, I suggest putting that on the APP server, but it’s up to you, you can run it on multiple servers
  • For the managed accounts, only update the username and passwords
• Services tab
  • On this page, we define our splits for core farm services, like the web application service (WFE), the timer, outgoing email and the distributed cache
  • It’s generally recommended to keep the distributed cache function with the WFE
• Logging
  • Here we define settings for the usage and tracing logs (think ULS)
  • The defaults make some good recommendations for compressing the logs, and limiting the usage.  I highly recommend you limit the Log Disk usage for both Usage and ULS logging
  • It’s also best practice to move the logs to a different drive than the OS but its up to you
• Web Applications
  • Setup your web applications as you see fit.  There is an intranet and My Sites web applications by default
  • You just need to update the URLs for the web app and the site collections
  • Pay close attention to the URLs and ports, ensuring if you’re using HTTPS use port 443, and HTTP uses 80
  • There’s a wrong path in the site collections, for the Search Center URL.  It will have http://portal.contoso.com/search by default.  This should be http://portal.contoso.com/search/pages.  If you have a different URL, just append /pages to whatever your search center URL is
• Service Applications
• Most of the service applications have very few settings except for items like the User Profile and Search
• For the User Profile, check the box to Enable NetBIOS Domain Names if you’re AD domain name as NETBIOS is different than the FQDN version (NetBIOS = CONTOSO.local, FQDN = CONTOSO.company.com)
• It’s good practice to only install the services that you need / will use, so if you don’t know what some services are, look them up and activate accordingly (like Work Management, Machine Translation, etc.)
• Regarding Apps, this will ONLY configure the Apps Service Application.  It will NOT configure all the necessary DNS configurations that are necessary for Apps to function.  Just specify the App domain, and the prefix on the Subscription service (App Site Subscription Name)
• If you’re configuring Access Services 2013, be sure to read the TechNet info to ensure your service accounts have all the right permissions
• For the Secure Store, the default key is set as the same as the farm passphrase
• For the Search Service, be sure to configure the Search Topology as you desire.  My setup was outlined in part 1 of this series
• Enterprise Service Apps
• For enterprise services like Excel and Visio, you will need to specify an unattended service account
• Other
• These settings are just for configuring the PDF icon and if you want Project Server
• This will get MUCH easier in SharePoint 2016 as Project Server becomes a standard builtin service application, but for now it’s a separate install and configuration
• The manual install is a pain, so if you can install it at the same time as SharePoint, DO IT.  It will save you hours of time re-applying service packs and CU updates

When  you’re done, click Review & Download.  It will have a text box with XML in it.  Just select it all, copy, and paste it into a blank notepad.  Save this as AutoSPInstaller-<servername>.XML and into the \AutoSPInstaller folder.  It’s the same directory as the PowerShell functions and installer launch batch file. 

Test SQL connection (optional)

For good measure, I always like to pre-create the SQL alias on all SharePoint servers using cliconfg, and on each server, test the connection to SQL (though you can do it with the script).  This will give you confidence all firewalls and other issues won’t bite you during the install.  You can do this easily by creating a new text file on the server desktop, then rename it to test.udl.  Double-click on the file, and type the name of the SQL alias in the server box, and click Test Connection.  If all is ok, it will succeed and you’re free to continue:

Installation

Now that you’ve done all your homework and prep, we’re ready to start the installation.  On the root App server, we can kick off the installation.  I like to move the entire \SP folder to the root of the C: drive, and per the documentation known issues its best to create a share and run the installer from the UNC path in remote install scenarios.  Set the share permissions for everyone full control, then set the NTFS permissions as indicated.  This In a multi-server scenario, be sure to drag the XML file on the launch.bat file to kick off the install.  It will do some sweet account and permission validation.

The installer will kick off the prereqinstaller, which you can open from the taskbar to watch it if you like.  Assuming you did all the .Net 3.5 stuff, it should not error and reboot a couple times.  Each time just log back in when the box comes back up, and the installer should launch and continue.  This just runs the prereqinstaller.exe file in the main \SharePoint folder.  The main installer should launch:

That setup will complete, then the AutoSPInstaller will find the May 2015 CU and install it:

This can take a long time so be patient (mine took 40 minutes).  Once that completes, it will ask you to hit Y to proceed with farm configuration.  Do that and it will build and configure the farm:

I prefer to put Central Admin on the root App server, not the WFE.  Next it will create the necessary managed accounts, then create the web applications that were specified.  Once it gets all the web apps and site collections created, it moves on the service applications. 

It is truly a beautiful thing when you get to see the User Profile Sync Provisioning say Online.  It just makes you feel all giddy inside.  It means you configured all the special permissions for the user profile sync account successfully, the farm account is a local admin during provisioning, etc.  If you’ve ever had this not work or had to fight with it especially in the early SharePoint 2010 days, you will understand.  Once we’re past the UPA, the only real hurdle left is Search because the other service applications are easy.  Search has a lot of things going on, services, topologies and components to activate and configure.

When it runs on the Search Server:

Then we move on to more service applications and make a few final configurations.  Once that’s done, guess what, you’re DONE!  Well, at least for the first App server.  Once done, it fires up Central Admin and all web apps and site collections it created.  If this was the only server, you would be done!  

In case, we have another server.  If you’re lucky and double-checked yourself and did all the checking up front, the install will actually complete without any errors on the first run.  It loads a new PowerShell window with the name of the remote server, and starts running through the script.  Notice that after it installs the binaries and the May 2015 CU, it joins the existing farm:

The rest will go faster because the farm and webapps are already built:

It will go and load balance the service applications as you defined in the answer file, and configure the search topology split across the servers as I showed earlier.  Once it completes, you should be seeing green!

Post-Install Configuration

Once we’re all done, there’s a few things we can take care of post configuration.  I won’t walk you through all of them, but let me try to document what else generally needs to be done to get your farm configured and more usable:

In Central Administration

• Create the AD user Profile Sync connection
• Choose the top most OU that has all of the users in it, but DO NOT choose the whole domain
• It’s definitely best practice to filter for only active users.  Do this by setting the useraccountcontrol attribute for bit on equals to 2
• Run a full user profile import and ensure there are no errors (C:\Program Files\Microsoft Office Servers\15.0\Synchronization Service\UIShell\miisclient.exe)

• Configure Apps
• Create an app catalog in your main web application
• Create an empty web application on port 80 with no host header
• Restrict the app permissions so end users can’t directly add apps without admin approval (radio button in App settings)
• Configure warmup scripts
• Configure Search
• Configure your crawl schedules or continuous crawl
• Unless you have 100 users or something small, it’s a good idea to move the people search (mysite and people search URLs) into a separate content source and schedule as they don’t need to be crawled as the same rate as main content

• Ensure that the topology is as you defined:

• Run full crawls (if not using continuous crawls)
• Add any site collection administrators

In SQL

• Check all content databases autogrowth settings and set according to best practice
• Pre-grow the content DBs to the size you expect after 1 year of usage (use the Initial size setting)
• Set the Config database recovery model to Simple
• There’s an issue I’ve seen with permissions on stored procedures in the Configuration database.  You will see these manifest as event viewer errors, complaining about one or all of these 4 stored procs:
• Proc_GetTimerRunningJobs
• Proc_putObjectTVP
• Proc_putObject
• Proc_putDependency
• You’re looking for errors like this:

• You can manually go into the stored procedures and add the EXECUTE permission manually to the service application pool account, or use this script:

use

GO

GRANT EXECUTE ON [dbo].[proc_GetTimerRunningJobs] TO

GRANT EXECUTE ON [dbo].[proc_putObjectTVP] TO

GRANT EXECUTE ON [dbo].[proc_putObject] TO

GRANT EXECUTE ON [dbo].[proc_putDependency] TO

GO

• Replace the domain\user with the user mentioned in the error, and the name of the Config database in the Use statement.  I take no responsibility for anyone running this and use at your own risk – please test on a test server first

Workflow Manager

You didn’t say you wanted workflows did you?  AutoSPInstaller does not account for this, and a step by step is out of the scope of this article.  However, let me call out a few points:

• In an App / WFE environment, the Workflow Manager should be installed on the application servers, and the workflow client only needs to be installed on the WFE servers
• When configuring the SQL server and databases, ensure you continue to use the SQL alias
• When using SSL, it’s good to first test the URL to ensure the web service connects after the config qizard is successful by going to the server FQDN on port 12290 like https://APP01.contoso.com:12290.  If you get a certificate error instead opening normal, run the following powershell:
• Powershell
• $rootCert = (Get-SPCertificateAuthority).RootCertificate
• $rootCert.Export("Cert") | Set-Content C:\SharePointRootAuthority.cer -Encoding byte
• Right click the .cer file, and install it to the Trusted Root Certificate Authority for the Computer account.  Do this on both the App and WFE servers
• Try again, and it should render XML with no cert error
• You can test it’s wired by going to Central Admin –> Service Applications, and click on the Workflow Service Application Proxy, and ensure it says Workflow is Connected
• Then you can use SharePoint Designer, create a new workflow, and see if you get both 2010 and 2013 options

I hope this series has been helpful for you to get familiar with using the AutoSPInstaller tool.  Let us know how we can help you install SharePoint 2013 and contact us!