Organizing SharePoint projects–Installation

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.

Preparations

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:
  

  <?xml version="1.0" encoding="utf-8" ?>

  <Accounts>

    <Account Name="PGGM-INTRA\sp-Farm-d"><![CDATA[password=r+)L;}=0L+5C'<O]]></Account>

    ....

    <Account Name="PGGM-INTRA\svcSQL-SPDBServer"><![CDATA[password=J8r2)881STc2mL1]]></Account>

  </Accounts>

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

Settings file

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:

  <Binaries>

    <SQLServerR2 displayname="Sql Server 2008 R2" location="D:\setup.exe" />

  
    <SQLManagementObjects displayname="Microsoft SQL Server 2008 Management Objects" 
  
      location="Z:\OTAP2010Binaries\SQL2008ManagementObjects\SharedManagementObjects.msi" />
  

    <SharePointHotfix_NetFramework35 displayname=".Net FrameWork 3.5 Hotfix" 

      location="Z:\OTAP2010Binaries\HotFixes\Windows6.1-KB976462-v2-x64.msu" />

    <SharePoint displayname="SharePoint 2010 RTM" 

      location="Z:\OTAP2010Binaries\sp2010RTM\setup.exe" />

    <SharePointLPDutch displayname="SharePoint Server 2010 Dutch Language Pack" 

      location="Z:\OTAP2010Binaries\sp2010lp_dutch\setup.exe" />

    <SharePointCU201108 displayname="SharePoint 2010 Augustus 2011 CU"

      location="E:\Install\OTAP2010Binaries\SP2010_CU201108\office2010-kb2553048-fullfile-x64-glb.exe" />

    <PowerGui displayname="PowerGUI.2.3.0.1503" 

      location="\\XXX\OTAP2010Binaries\PowerGUI\PowerGUI.2.3.0.1503.msi" />

  </Binaries>

• 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:

  <Topology>

    <Server Name="localhost">

      <Disable_ConfigTasksScreenAtLogon />

      <Install_DotNetFramework />

    </Server>

    <!--DataBaseServer-->

    <Server Name="STTO-SSQL" >

      <Install_SQL2008R2 />

    </Server>

    <!--Web Front-End-->

    <Server Name="STTO-SPWFE" >

      <Create_SQLAliases />

      <InstallSQLManagementObjects />

      <Install_SharePoint />

      <JoinFarm />

      <Configure_ServiceApp_EnterpriseSearch >

        <QueryComponent />

      </Configure_ServiceApp_EnterpriseSearch>

    </Server>

    <!--ApplicationServer-->

    <Server Name="STTO-SPAPP" >

      <Create_SQLAliases />

      <InstallSQLManagementObjects />

      <Install_SharePoint />

      <CreateFarm />

      <Create_WebApp_CentralAdmin />

      <Configure_ServiceApp_ManagedMetadata />

     ....

      <Create_WebApplications_And_Sites />

      <Create_Subscriptions />

    </Server>

  </Topology>

  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:

  <Domain>

    <DomainName>STTO</DomainName>

    <DNSDomainName>stto.local</DNSDomainName>

  </Domain>

• SQLAliases– One or more SQL Aliases to create on the server. For my demo setup it looks like this:

  <SQLAliases>

    <SQLAlias Name="SPDBServer" Value="STTO-SQL" />

  </SQLAliases>

• SQL2008R2 – Settings for configuring SQL Server. I will cover this bit in more detail in the next blogpost. My demo configuration:

  <SQL2008R2>

    <SQLEngineServiceAccount>PGGM-INTRA\svcSQL-SPDBServer</SQLEngineServiceAccount>

    <SQLSysAdminAccounts>Builtin\Administrators</SQLSysAdminAccounts>

    <INSTALLSHAREDDIR>C:\Program Files\Microsoft SQL Server</INSTALLSHAREDDIR>

    <INSTALLSHAREDWOWDIR>C:\Program Files (x86)\Microsoft SQL Server</INSTALLSHAREDWOWDIR>

    <INSTANCEDIR>C:\Program Files\Microsoft SQL Server</INSTANCEDIR>

    <SQLTEMPDBDIR>C:\SQLData</SQLTEMPDBDIR>

    <SQLTEMPDBLOGDIR>C:\SQLTransactionLog</SQLTEMPDBLOGDIR>

    <SQLUSERDBDIR>C:\SQLData</SQLUSERDBDIR>

    <SQLUSERDBLOGDIR>C:\SQLTransactionLog</SQLUSERDBLOGDIR>

  </SQL2008R2>

• IIS– Element containing IIS settings, the most important being the folder where to put the configuration files (the wwwroot folder):

  <IIS>

    <Settings wwwroot="E:\STTOWEB" />

    <DisableLoopbackCheck value="true" />

  </IIS>

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

  <Farm

  DefaultDBServer="SPDBServer"

  DiagnosticLogLocation="E:\LogFiles\Diagnostic"

  Passphrase=STTO_$ecretP@$$fra$# 

  count="STTO\sp-farm-d"

  DebugScriptMode="False"

  OutgoingEmailServer="localhost"

  DefaultFromAddress="someone@stto.local"

  DefaultReplyToAddress="someone@stto.local"

  DefaultCodePage="65001" >

    <!--DebugScriptMode deletes existing datebases-->

    <DisableUnneededServices value="true" />

    <ConfigurationDatabase Name="Config" Recovery="Simple" InitDataSizeInMB="125"

             GrowthDataSizeInMB="50" InitLogSizeInMB="50" GrowthLogSizeInMB="50" />

  </Farm>

• 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:

  <WebApplications>

    <CentralAdmin Name="SharePoint Central Admininistration v4"

             Port="51000">

      <ExtendWebApp Name="SharePoint Central Admininistration v4 - extended"

             Path="E:\STTOWEB\centraladmin_extended"

             Zone="Intranet"

             Url="http://centraladmin-d"

             Hostheader="centraladmin-d"

             Port="80" />

      <ApplicationPool Name="SharePoint Central Admininistration AppPool - D"

             Account="PGGM-INTRA\sp-farm-d" />

      <Database DbServer="Default"

             Recovery="Simple"

             Name="Content_CentralAdmin_D"

             InitDataSizeInMB="200"

             GrowthDataSizeInMB="50"

             InitLogSizeInMB="100"

             GrowthLogSizeInMB="50" />

    </CentralAdmin>

  </WebApplications>

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

  <Services>

    <ManagedMetadataService Name="Managed Metadata Service"

            MultiTenant="True"

            ContentTypePushdownEnabled="True"

            DefaultKeywordTaxonomy="True"

            DefaultSiteCollectionTaxonomy="True" >

      <Application Name="Managed Metadata Service App - D" >

        <ApplicationPool Name="Managed Metadata Service App - D"

                Account="PGGM-INTRA\sp-MMS-d" />

        <Database DbServer="Default"

                Recovery="Simple"

                Name="ServiceApp_ManagedMetadata_B"

                InitDataSizeInMB="50"

                GrowthDataSizeInMB="50"

                InitLogSizeInMB="10"

                GrowthLogSizeInMB="25" />

      </Application>

    </ManagedMetadataService>

  </Services>

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

Finally

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.