Provisioning a New SharePoint Farm with no Database GUIDs
SharePoint 2013 has reached RTM and we've been having fun evaluating it. As an infrastructure guy one of the first things I think about is deployment; how am I going to deploy this thing? Of course I hate GUIDs in my database names and we see pretty quickly that during the initial installation the config DB still has a GUID in the name if we install the bits and run the Config Wizard.
Well I wanted to see if my approach from SharePoint 2010 still works, and it does. So after I've installed the SharePoint 2013 bits I make a point of UN-CHECKING that box to run the config wizard.
In addition to avoiding GUIDs in DB names I've got a few other things I like to do; setup central admin to run on port 80 and use kerberos. Sure you might be saying, wo-now why aren't you putting this on 443? Well we can do that also but for this example I'm going to use 80 and kerb, I agree we should put Central Admin on 443 since sometimes we might want to type passwords in there, but I don't want to get into managing your SSL certs in this example. I'm going to assume you have nothing running on the default web site in IIS since the script that follows here removes that default web site. Your also going to want to make sure you have an SPN, DNS Host (A) record and corresponding pointer (PTR) record statically configured for your SharePoint servers Central Administration URL.
So in my example I'll need:
- A DNS* Host (A) record 'spadmin-myfarm.mydemo.com' pointing to 192.168.50.10
- A DNS PTR record in my reverse lookup zone 192.168.50.10 that points back to 'spadmin-myfarm.mydemo.com'
- A service principle name registered for the service name 'http/spadmin-myfarm.mydemo.com' under the AD user principle mydemo\spfarm
- An install user account called mydemo\spinstall who is a local server administrator on the SharePoint server and has the DBCreator and SecurityAdmin roles in my back end SQL server
- I've disabled IE ESC, loopback check and UAC on the SP server also, and my PowerShell Execution Policy is set to remote signed
*Note; you may have multiple forward and reverse records mapping names to IP's and back in DNS depending on how you have your infrastructure configured. I stay clear of using the checkbox 'update associated pointer (PTR) record' in the Windows DNS console and add my PTR records manually. In the example here I have two PTR records for 192.168.50.10; one for spservera.mydemo.com, which is the real name of my server, and one for 'spadmin-myfarm.mydemo.com', which is the url of my central admin.
Now that I've got the SP Server Pre-Reqs installed, and the SP Server binaries done too, as well as those bits in DNS and a couple of AD user accounts ready for the Farm and Install users with the correct local and SQL permissions, I'm ready to fire up PowerShell, as the install user, and run my script to provision a new farm, instead of running that GUID loving config wizard.
When you run this script you should be prompted for a farm passphrase and then be presented with a credential tile; put the creds for the Farm Account in when you see the tile.
Here's the script Provision-SPFarm.ps1:
# Script Creates a new Farm
# Must be run as the install user
# Install user must be a local admin on the SharePoint server
# Install user must have DBCreator and SecurityAdmin roles on SQL Server
# SP and Pre-reqs must be installed
# Version 1.0
#
# Ensure you edit the variables correctly
#
##########################
# Change These Variables #
##########################
# FarmName should uniquely identify the farm
$FarmName = "MyFarm"
# DBServer Should be the FQDN of the supporting SQL instance
$DBServer = "sql.mydemo.com"
$centraladmindomain = ".mydemo.com"
#################################
# DO NOT CHANGE These Variables #
#################################
# Config DB Name
$ConfigDBName = $FarmName + "_Config"
# Admin Content DB Name
$AdminContentDBName = $FarmName + "_Admin"
$FarmPassPhrase = Read-Host 'Enter Farm PassPhrase'
$computerName = "$env:computername"
$LocalHostUrl = "http://" + $computerName
$CentralAdmin = "spadmin-" + $FarmName + $centraladmindomain
$CentralAdminUrl = "http://" + $CentralAdmin
Add-PSSnapin "Microsoft.SharePoint.PowerShell"
Write-Host "You will be prompted for the credentials of the farm account! Please enter the domain\username and password at the credential tile!"
PAUSE
New-SPConfigurationDatabase -DatabaseName $ConfigDBName -DatabaseServer $DBServer -AdministrationContentDatabaseName $AdminContentDBName -Passphrase (ConvertTo-SecureString $FarmPassPhrase -AsPlainText -Force) -FarmCredentials (Get-Credential)
#Add Central Admin
New-SPCentralAdministration -Port 80 -WindowsAuthProvider "Kerberos"
Set-SPAlternateURL -Identity $LocalHostUrl -url $CentralAdminUrl -zone default
#IIS Maintenance
Import-Module WebAdministration
New-WebBinding -Name 'SharePoint Central Administration v4' -IPAddress "*" -Port 80 -HostHeader $CentralAdmin
Remove-WebBinding -Name 'SharePoint Central Administration v4' -IPAddress "*" -Port 80 -HostHeader "*"
Remove-Website -Name 'Default Web Site'
Start-Website -Name 'SharePoint Central Administration v4'
#Install SP Features and Content
Install-SPApplicationContent
Install-SPHelpCollection -All
Initialize-SPResourceSecurity
Install-SPFeature -AllExistingFeatures
Install-SPService
#Echo the url of the central admin
Write-host
$CentralAdminUrl
write-host " is the url of the central administration for the farm"
pause
#Done
You should now be able to browse to Central admin using the url http://spadmin-MyFarm.mydomain.com with no silly GUIDs in the SQL database names. I usually use wireshark, or klist to verify kerberos is working (you got in right? kerberos is working!)
This is not perfect but is how I've been provisioning central admin for a while. Comments are welcome. I enjoy a healthy debate!
I can't promise this will work in your environment and if bad things happen like meteors crashing out of the air or your servers exploding I take no responsibility. The opinions expressed here are my own and not my companies.
Happy SharePointing!
