When the binaries are installed on the
server and we have a Microsoft SQL Server instance
available, the first thing we need to do is create a configuration
database. The configuration database is the heart of a SharePoint farm
and contains more or less all global settings. Without the configuration
database, a SharePoint farm would not function.
To create this new database we use the New-SPConfigurationDatabase
cmdlet. This cmdlet requires that we specify the database name and the
name of the database server instance, as well as the name of the content
database associated with the Central Administration web application,
the credentials of the farm account to use, and the passphrase used when
adding extra servers to the farm.
So, to begin, we specify the name of the database. Storing information in variables allows us to reuse the variables.
PS > $dbName = "NimaIntranet_ConfigDB"
Setting the database name is an option available when
performing a setup using Windows PowerShell (or STSADM). This is one of the main
reasons for using a scripted installation: You are able to control the
database name and align it with corporate naming standards.
We also specify the name of the SQL Server instance
that we will use and the name for the Central Administration content
database.
PS > $dbServer = "SQLServer01"
PS > $centralAdmindbName = "NimaIntranet_Admin_ContentDB"
The New-SPConfigurationDatabase cmdlet also requires the Passphrase parameter. A passphrase
is a new addition in SharePoint 2010. It is a “farm password” used for
generating the farm encryption key (master key), which is used for
securing managed accounts and credentials stored in the Secure Store
Service. In addition, the passphrase is used when adding new servers to
the farm.
The Passphrase parameter requires an object of the type System.Security.SecureString as input. By using the ConvertTo-SecureString cmdlet, we can create a secure string in Window PowerShell, as in this example:
PS > $securePassPhrase =
>> (ConvertTo-SecureString -String "pass@word1" -AsPlaintext -Force)
The SecureString cmdlets in Windows
PowerShell use the Windows Data Protection API when working with secure
strings. This API is the standard way a Windows program protects
sensitive data. The encryption key is based on logon credentials.
We also add the credentials used for the farm administrator account using the FarmCredentials parameter. The parameter requires a System.Management.Automation.PSCredential object as input. Windows PowerShell includes the Get-Credential cmdlet, which prompts the user for password (or a username and password) and returns a PSCredential object to the session. However, since we are going for an automated installation, we will create a PSCredential object using the New-Object cmdlet. Before we can create a PSCredential object, we need to create a secure string containing the user password, since the PSCredential object constructor accepts only secure strings as input for the password argument.
PS > $userName = "powershell\administrator"
PS > $password = "P@ssword1"
PS > $securePassword =
>> ConvertTo-SecureString -string $password -AsPlainText -Force
PS > $psCredentials =
>> New-Object -TypeName System.Management.Automation.PSCredential `
>> -ArgumentList $userName, $securePassword
Now
that we have collected all the necessary input information and stored
it conveniently in variables, we can go ahead and run the
New-SPConfigurationDatabase cmdlet:
PS > New-SPConfigurationDatabase -DatabaseName $databaseName `
>> -DatabaseServer $databaseServer `
>> -AdministrationContentDatabaseName $centralAdminDatabase `
>> -Passphrase $securePassPhrase -FarmCredentials $psCredentials
The next step in the process of installing a
SharePoint 2010 farm is to install the Help files. If a custom Help file
or only a specific file should be used, you can use the LiteralPath
parameter. In most cases, you will use the All parameter to install all
available Help collections, like this:
PS > Install-SPHelpCollection -All
We also want to enforce security for all resources,
including files, folders, and registry keys. This is done by using the
Initialize-SPResourceSecurity cmdlet:
PS > Initialize-SPResourceSecurity
Now we need to install the necessary services and features in our farm. The services are installed using the Install-SPService cmdlet. The cmdlet installs all services, service instances, and service proxies specified in the registry on the server. Install-SPService also supports the Provision parameter used for stand-alone servers only.
The features are installed using the
Install-SPFeature cmdlet. The cmdlet supports the AllExistingFeatures
switch parameter, which installs all the existing features on the
server.
The following example demonstrates how to use these two cmdlets.
PS > Install-SPService
PS > Install-SPFeature -AllExistingFeatures
We can manage the SharePoint 2010 environment through
the Central Administration site, but before we can access it, we must
provision a new site using the New-SPCentralAdministration
cmdlet. The cmdlet creates a new web application with the Central
Administration site collection at the root, using the port and
authentication provider specified with the parameters Port and WindowsAuthProvider, as shown in the following example.
PS > New-SPCentralAdministration -Port 8000 -WindowsAuthProvider "NTLM"
The last step in the installation is to copy the
shared application data to the web application folders. We can achieve
this using the Install-SPApplicationContent cmdlet.
PS > Install-SPApplicationContent
Tip
Since none of the cmdlets used in this scenario produce any output, you can use the Verbose switch parameter on the cmdlets to get a detailed output of what each actually does. An example is Install-SPApplicationContent -Verbose.