In part five of my building a multi-server SharePoint dev environment series we are going to install SharePoint 2013. But first I am going to cover how to create the AutoSPInstaller Answer File. We will do this using the AutoSPInstaller online tool. There isn’t a lot of information out there on it (that I could find) so I hope it is helpful. I am going to go through each area in pretty decent detail, but to make things easier for you, I will also provide my answer file that you can easily modify for your needs. Once we have finished creating the answer file I will show you how to kick off the install of SharePoint.

Posts in this series:


Farm Architecture

I chose to go with the traditional model for my SP architecture. The main reason is that there is pretty much complete separation of web and app functionality in the farm. I will not have hundreds or thousands of users accessing my environment so I felt I didn’t have a need for a streamlined approach. However, there is no reason this can’t be changed and AutoSPInstaller makes it really easy (just select the WFE or other server in your provision settings for each service). I wasn’t going to get too much into the different approaches in the post so please check out this TechNet document on provisioning for different architectures.

When you get to the Web App portion below. Notice that I have not created a separate Web App for MySites. This is because I am designing this using Host Named Site Collections (HNSC). Microsoft recommends that when using HNSC to place everything, including MySites under the same Web Application.

Something to consider with HNSC and MySites

I would like to put a caveat here. Microsoft recommends maintaining a single Web App with HNSC. However, what they do not come out and tell you is that you will NOT have control of the content DBs used. The only way you can do this is to leave the DB you want to use for MySites with the default number of openings for new site collections and decrease the other content DB connections so site collections will not be created within them. While it will force all new users into the MySite DB for their sites, it is not a perfect solution as each time you create a new site collection elsewhere you will need to increment the number of connections to the DB you want to use each time or else they will go into the MySite DB. You can modify your site collection script to do this for you automatically, but it is something to consider.

AutoSPInstaller Answer File

This is probably going to be the most time consuming portion of the entire process, but once done you can use it again and again. What’s nice, is you can easily mod it for other installs or give to a colleague for them to setup their environment. This is a dev server so I am going to enable everything cause you never know when you are going to be working on something new. Do not do this for your Prod and Pre-Prod environments (only enable what you need at the time).

  1. Navigate to and click on Build a Farm


  1. If you already have a template you want to use for your file you can upload and modify it here, but for the purpose of this post I am going to start from scratch. Click on Begin With Template. This will basically load a base config file and allow you to modify all the settings for your needs. All the provisioning will be disabled so you only need to select what you want to enable on the left menu.
  2. On the servers list add the two SP servers’ host name:
  3. Notice that if you only enter one server, you receive an error? This is because for single server installs, the script should not use host names. However, if you are going to use remote installation, then you need at least 2 servers. Also notice the exclamations on the other menus. This indicates your current script config has errors at these locations.


  1. Once you have entered the server names, select the Install menu on the left navigation pane.
  2. Since this post is for setting up a Dev environment you can leave the Environment Name as it is, but if you want something else go ahead.
  3. Most of the options here are left as is but you do want to enable a couple of options:
    • Offline Install – We will be using this because we will be packaging everything up with AutoSPSourceBuilder
    • Remote Install – This configures the script to use the server it is running on as the central server and remotely install the other servers in the list.
    • Auto Logon and the corresponding password – So you don’t have to enter the password at all the different required positions in the install.
    • Leave all other options as defaulted
    • Next in the Unattended Install section set the options as follows:
      • Set the name you want for the config file that SP uses for the binaries (AutoSPInstaller creates this for you).
      • Set Install Directory to C:\SharePoint\SP
      • Data Directory: C:\SharePoint_Data. You can set another drive, if you add another drive to your VM, but make sure both SP VMs have the same drive
      • Select the SKU you are installing
      • Enter your License Key
  4. Under the Farm tab select Main. There are a lot of options here and they are all pretty self-explanatory. Fill them in as you feel necessary.
    • In the Database section, create the alias you want to use for your DB (ex. spDevDB) and fill in the DB instance information.
    • Also ensure you set the prefix you want to use for all of your databases.
      • Note: Normally you would leave this version agnostic, however if you are running multiple versions of SP against this SQL Server and didn’t set up instances for each, then you may actually want to indicate the version the database points to.
    • Set the provision option for Central Admin to your App server
    • Update your managed accounts and add any you feel you will need (ensure they match the accounts you created in Part 2 of the series).
  5. Click on Services. Here you will select which servers will run the farm services. What’s nice is you simply have to select to provision on all, provision on a particular server or not provision at all. Enable the services as follows:
    • Web Application Service: WFE
    • Workflow Timer Service: APP
    • Distributed Cache Service: WFE
    • Claims to Windows Service: WFE
      • Do NOT enable Update Claims to Windows Service Account
    • Sandbox Code Service: App
    • Do not provision the SMTP or Email services (unless you really want to).
  6. Click on Logging. This is pretty self explanatory. My suggestion is to set the log locations to the same location (C:\SharePointLogs). If you have a separate drive, best practice suggestion is to put them there.
  7. Now we deal with the Web Applications. We only need one, so if two are listed (by default) delete the MySite Web Application as MySites will be a HNSC under the main WebApp. I have called mine Intranet. I will list the settings I used, but you can use whatever you want:
    • Portal\Intranet
      • Name: Intranet
      • Application Pool Account: Your Sites App Pool
      • Application Pool Name: SiteAppPool
      • URL:
      • Port:80
      • Use Host Header: Leave unchecked (I am configuring for Host Named Site Collections, this should not get selected)
      • Leave everything else as default. But set your database name
      • Create one Managed Path. It can be “my”, “personal”, etc.
      • Teams Site Collection:
        • Site URL:
        • Host Named Site Collection: Checked
        • Web Template: Team Site
        • Content Database Name: … Teams_Content
        • Search Center URL:
        • Leave the rest at defaults
      • Search Site Collection:
        • Site URL:
        • Web Template: Enterprise Search Center
        • Content Database Name: … Search_Content
        • Modify the rest of the settings based on the search site and the same as the Teams Site.
      • MySites Site Collection:
        • Site URL:
        • Web Template: My Site Host
        • Content Database Name: … MySites
        • Modify the rest of the settings based on the search site and the same as the Teams Site.
  8. Next we are going to move on to the Service Applications. The choice is yours as to which services you want to install. Honestly, in a Dev environment I don’t see any issue with enabling everything. You never know what you are going to use when developing solutions or learning new things. Everything will get provisioned onto the App server, however when we get to search we will share some of the search duties on the WFE.
    1. Managed Metadata
      • Enable on the App server, but can leave everything here as defaults if you wish
    2. User Profile Service
      • Add your MySite Host location as set in the MySite Host Web Application section.
      • Set the managed path to the one you set in the web app.
      • Only check Enable NetBIOS Domain Names if the HOST or NETBIOS portion of your domain name in AD is different than your FQDN.
      • The rest can be left as defaults.
    3. Usage and Health
      • Enable on the App server, but can leave everything here as defaults if you wish
    4. State Service
      • Enable on the App server, but can leave everything here as defaults if you wish
    5. Search Service
      • You can leave everything at the default value unless I state differently.
      • This service gets provisioned on all the servers. Even if you don’t want it running on your other servers, still provision it there. Patching goes bad if it doesn’t find Search available on a server (even when not running).
      • Enter your email address
      • Custom Index Location: If you set the Data location as I suggested in the Install section (number 7 above) then do not put anything here as the index will be placed there. Otherwise, set the location you wish the index to be placed.
      • Proxy Type: I suggest a Reduced setting for a dev environment. You won’t need the extra threads.
      • Crawl Account: <domain>\SP_Crawl
      • Crawl Account Pwd: Password for the account
      • Search Center URL: http://search.<YourDomain>.com
      • Search Topology:
        • Admin Component: App Server
        • Query Component: WFE Server
        • Crawl Component: App Server
        • Search Query and Site Settings Component: App Server
        • Index Component: WFE Server
        • Content Processing Component: App Server
        • Analytics Component: App Server
    6. Secure Service
      • Enable on the App server, but can leave everything here as defaults if you wish
    7. Business Data Connectivity
      • Enable on the App server, but can leave everything here as defaults if you wish
    8. App Management
      • Enable on the App server
      • App Domain:
      • Leave remainder as defaulted
    9. Subscription Service
      • Enable on the App server
      • I changed the App Site Subscription Name to SP Dev Apps, but you can leave it and the rest to defaults if you wish
    10. Word Automation, Machine Translation, Work Management and PowerPoint Conversion services
      • Enable for App server, but can leave everything here as defaults if you wish
  9. The last section of the AutoSPInstaller Answer File is the Enterprise Service Apps. This will be the final section we need to complete. Special note: If you enable any of these services, ensure you create accounts for them. The Service Account Creator Tool used in part 2 does not create the accounts for these services.
    1. Excel Services
      • Enable on the App Server
      • Unattended Account: <Domain>\SP_Excel
    2. Visio Services
      • Enable on the App Server
      • Unattended Account: <Domain>\SP_Visio
    3. Access Services 2010
      • Enable on the App Server
      • Note: if you download my provided config file I chose to NOT enable this service
    4. Access Services 2013
      • Enable on the App Server
      • Note: if you download my provided config file I chose to NOT enable this service
    5. PerformancePoint Services
      • Enable on the App Server
      • Unattended Account: <Domain>\SP_PerformancePoint

That’s it. You have created your answer file. Now you simply click on Review & Download. Open notepad and copy the xml text from the Review & Download section into the notepad and save it as the name you gave the answer file in the settings. I suggest you give the config file some name you will be able to understand later and save it somewhere for later. However, when you copy it to C:\SharePoint\SP\AutoSPInstaller rename the copy to AutoSPInstallerInput.xml. This is what the batch launcher looks for.

As promised, here is the answer file I created using the options above. Just copy the text into Notepad and rename it to whatever you want as an xml. Just remember to change the domain, computer name and any other options that will differ in your environment from mine.

Install SharePoint with AutoSPInstaller

Next we are going to install SharePoint on the App server and remotely on the WFE server. Since we have done all this legwork ahead of time, this part is pretty straight forward. One thing we have to do because we will be doing a remote install is setup UNC share paths (\\servername\share) for the install locations. Myself, I shared C:\SharePoint and gave everyone write access. The reason for this is there is some documented issues around installing remotely that requires a UNC path to be used instead of a mapped drive or a local drive.

To install simply open a PowerShell window and run the following:

\\<Server Name>\SharePoint\SP\AutoSPInstaller\AutoSPInstaller.bat

You will be prompted once to enter the farm account password and you may get the odd UAC prompts (unless you chose to disable it). For the most part, the system will install everything on your app server and then will remotely install the rest on the WFE server.

Update Your Hosts File

So everything is setup and ready to go, except one last item. We need to update the hosts file to route to our sites properly. Don’t worry, I have a PowerShell script for you to run for that too 😉 Run the following on every server you think you will access the farm from:

ac -Encoding UTF8  C:\Windows\system32\drivers\etc\hosts ""
ac -Encoding UTF8  C:\Windows\system32\drivers\etc\hosts ""
ac -Encoding UTF8  C:\Windows\system32\drivers\etc\hosts ""


That’s it. You just finished installing SharePoint across multiple servers!

Setting up the Development Tools

Initially I had considered adding a final post to this series about setting up your development tools quickly and easily. However, after rereading Vlad’s post on this very thing I would rather direct you over to his site and follow the instructions he has already provided. So when setting up your development tools I encourage you to read up on how Vlad suggests you proceed.


If you save the scripts I provide you shouldn’t have any issue recreating your environments using the steps in this series. Let me know if you experience any issues.

Thanks for reading!