AutoSPInstaller: Prepare the Scripts
This post is part of a series covering how to configure and run AutoSPInstaller, a set of scripts that can be used to automatically install SharePoint. In this post, we will configure and prepare the configuration files that are needed to run the script.
More posts in the series:
- Automated SharePoint Installations: Step-by-step (Overview)
- Prepare Server Hardware, Software and System Accounts
- Preparing the Base Media
- Prepare Server for Unattended Installation
- Prepare the Scripts
- Executing the Scripts, Post-Execution Tasks
Prepare The Scripts
First of all, open the file config.xml and config-OWA.xml and enter the SharePoint 2010 product key under the PIDKEY parameter. Once done, open the files in Internet Explorer to ensure they open without errors, i.e. that they contain well formed XML. Alternatively, use an XML editor. Personally, I use Visual Studio.
Now rename the AutoSPInstallerInput.xml file by appending the name of your server. For example, AutoSPInstallerInput-SPQASRV7873.xml. By not having the original file present, we ensure that our environment specific file is loaded and forms a way of documenting the installation. You could also provide separate config.xml files with separate PIDs. To do this, rename the config.xml files and specify the new names in the AutoSPInstallerInput.xml file under the ConfigFile element.
Set the key OfflineInstall to true to enable the scripts to install our already downloaded prerequisites.
Notes for SharePoint 2013 Installations
Make sure to update the default search index location when using AutoSPInstaller for SharePoint 2013. By default, the location is under the 14 subfolder of “c:\Program Files\Microsoft Office Servers”.
That means that the index is placed in a custom location as far as the SP2013 setup is concerned. This results in an error being displayed stating “The filtering process has been terminated”. There seems to be an issue with permissions for the WSS_WPG group not being applied correctly. There’s a workaround described in an article by Victor Anthony Maceda.
Use the following command for indexes in custom locations:
Set-SPEnterpriseSearchServiceInstance -identity <computer name> -DefaultIndexLocation <path to where index should be>
Script Management GUI
There’s now a graphical interface for filling out the input file, which can be downloaded at http://autospinstallergui.codeplex.com. The tool will definitely save you time and ensure that the file is properly formatted.
Simultaneous Server Install
Version 3 supports installation of remote servers. If you are running on separate servers, you could really speed things up by installing the binaries on all farm servers at the same time. To do this, enable the RemoteInstall and ParallelInstall parameters:
Automatic Login for Unattended Installation
Set the AutoAdminLogon element parameter Enabled to True and enter your password. This will automatically logon the install account and resume the installation should the installation process require a reboot.
Disabling Features and Services
I leave all elements under the Disable section as is. This will remove loop back check and remove IE enhanced security, allowing me to use Central Administration properly later on.
The passphrase is used as a password to add servers to an existing farm. Add the passphrase to the Farm\Passphrase element. Note: Make sure that the farm passphrase is complex or the installation will fail!
Set the domain account and password for the farm account under Farm\Account. I leave the parameters AddToLocalAdminsDuringSetup and LeaveInLocalAdmins parameters alone to ensure least privilege installation.
Under Farm\CentralAdmin, specify which server(s) will run the Central Administration site. I do this by setting the Provision element to one or more server names, such as:
Specify the alias name for the connection. This is highly recommended! Set the DBServer element to the name of the alias and specify the actual server name under the DBAlias\DBInstance section. Also, you might want to change the port from 1433 to a non-standards port in a production environment for security hardening purposes:
Farm services are configured under Farm\Services. Personally, I use the sandboxed code service for a number of things and want it available for others. I might also need to convert claims logins to AD accounts later on. I also want incoming (yes, installing SMTP is the answer!) and outgoing emails working so I configure these as well:
Configuring Managed Accounts and Service Accounts
This section is where most people get problems. Review the accounts that were created in the Prepare Server Hardware, Software and System Accounts section.
- Usernames are added to the Farm\ManagedAccounts section without domain or by using the default “DOMAIN\” text. Double-check this and do a quick search of the document for “DOMAIN\”
- The “CommonName” entries have been removed, changed or some accounts have been removed. If you, for some reason, are using one account for all services under Farm\ManagedAccounts, don’t delete the sections – duplicate the login details.
- The account entries in the actual service declarations are not set. Again, searching for “DOMAIN\” across the document will ensure that you don’t run into this problem.
Map the service accounts, and their passwords, from the Prepare Server Hardware, Software and System Accounts section into the following XML nodes and elements:
XML Configuration and location