In a previous post I have described our SharePoint 2010 DTAP street. We have quite a number of environments, so it is pretty important to make installation of SharePoint 2010 easy. When we started with SharePoint 2010 in May 2010, the first thing we did was to create a set of installation scripts to install every single farm in our environment. Donald Hessing gave us a kick start and Niels Loup and Ferdi Meijer added scripting to that so that we could:
- Install SharePoint unattended to single- and multi server topologies
- Run an automated install of all prerequisites (including SQL Server)
- Install tooling used by developers (also unattended)
- Have nice database names for SharePoint databases
- Have all dev and test machines in the same setup as production
- same least privileged setup for accounts
- same multi-tenant setup
- same web applications
- Cleanup and rebuild development machines easily
- Have repeatable deployments
Our OTAP Installer (which is Dutch for DTAP) starts with a fresh installed Windows 2008 R2 server (or a set of) and when it’s done, we have SharePoint 2010 deployed in a multi tenant setup, with a number of tenants configured and all web applications configured, including a dummy site collection. It is up to the Project Installer (more on that in a later blogpost) to install and configure SharePoint for specific projects.
A lot has been written about SharePoint installation using Powershell, and AutoSPInstaller is available so I won’t post all scripts here (unless you ask me to ), but I will show some bits and pieces.
Here is what the installer needs as input before we start it:
- a clean set of Windows servers
- the installer account has administrative permissions on all servers
- a settings.xml file that contains the topology for the servers, the services that run on each server and all settings that are used throughout the installation process. for more information, see below
- a sites.xml file that contains settings for the web applications to create (more on this in a future post)
- all accounts available in the AD. We use a specific set of accounts for each environment. All accounts have a fixed prefix, followed by an environment specific suffix. The farm account for our development servers for example, is called sp-farm-d and for acceptance it is called sp-farm-a.
- a password.xml file that contains all passwords for the accounts that we us in the setup. In our environment this password file is locked somewhere on a file share and the installer account is the only account having read access to it. It looks like this:
- access to a file share with all binaries
The scripts are written in a way that they first check if the actions haven’t already been done before. If so, they skip the action. This way we can always restart the script on every server when something went wrong, or we need to re-configure the server/farm.
The OTAP Installer uses a XML file that has all the settings for the installation. It contains a number of elements:
- Binaries– Contains the references to all binaries we need throughout the installation. It looks like this:
- Topology– This element contains all servers in the farm and for every server, the instructions for installation and configuration. The actions for server ‘localhost’ are run on every server in the farm. A brief example:
In a normal settings.xml file, the application server would typically contains more service applications to configure. I have omitted them here to keep this post short.
- General– General settings like the reference to the password file
- Domain– Domain name. For my demo domain:
- SQLAliases– One or more SQL Aliases to create on the server. For my demo setup it looks like this:
- SQL2008R2 – Settings for configuring SQL Server. I will cover this bit in more detail in the next blogpost. My demo configuration:
- IIS– Element containing IIS settings, the most important being the folder where to put the configuration files (the wwwroot folder):
- Farm– XML element with the options to configure the farm. Important settings here are name and SQL settings for the Configuration database and the farm account.
- WebApplications– The WebApplications element lets you configure the Central Admin web application that you want to have in your farm. After creating the database and the web application, the script extends the central administration web application, to have a custom Url:
- Services – This is the biggest element in the configuration file. It contains the configuration of all service applications that we will use in our farm. Please note that this element contains the configuration for the service application. The Topologyelement decides on which server the service app will run. For the purpose of this blog post, it only shows the example configuration of the MMS (Managed Metadata Service) service application:
This MSS service application is created as a multi tenant service application.
running the scripts
After all preparations are done, it is time to start the installation. To do this an administrator logs into a server using the installer account (in my example this is sp-install-d), starts a PowerShell command prompt (using Run as Administrator) and starts the installer. The installer loads settings.xml and reads that file to find the instruction for the current server. The order of installation:
- Database server
- Application server / servers
- Web Front end server / servers
This blogpost is a general introduction to our OTAP installer. It gives you a basic idea how the installer works and how to configure it. In the next few posts I will cover some aspects of the installation process in more detail. If you are interested in specific part, please contact me and I will handle those parts first.