Install SharePoint 2013 with PowerShell to Prevent the Dreaded Database Names with GUID’s

Do you have a shared SQL Server back-end for multiple SharePoint farms? Do you like being able to easily tell which SharePoint databases go with which SharePoint farm? If you install SharePoint 2013 using the GUI wizard, you’ll end up with database names that have GUID’s on them that look like this:


This blog will guide you through installing SharePoint Foundation 2013 with PowerShell so you’ll have full control over the database names. This process is very similar to installing SharePoint Foundation 2010 which I’ve previously blogged about in more detail.

While it is possible to install SharePoint on a single server, it’s definitely not recommended for a production environment. The process that I’m going through in this blog uses what I consider to be the bare minimum configuration (in my opinion) which is one server dedicated to SQL Server that can be a shared database server but doesn’t perform any other roles in your data-center, the second server is a dedicated SharePoint web front-end server.

First, download SharePoint Foundation 2013, make sure the servers you plan to install SharePoint on meet the hardware and software requirements and read the installation guide:


Create three service accounts. A farm account, an install account, and an application pool account (this is the minimum number of service accounts). I’m running this PowerShell script from a Windows 8 workstation that’s a member of the domain. I’m using implicit remoting so I don’t have to install the Remote Server Administration Tools on this workstation since it’s a temporary test environment and I’m only importing a single cmdlet (New-ADUser) to maintain maximum security since that’s the only cmdlet in the Active Directory module that this script uses. I’ve also specified the -Credential parameter since the user I’m running PowerShell as doesn’t have rights to create an Active Directory user account.

Import-PSSession -Session (
New-PSSession -ComputerName dc01 -Credential (Get-Credential)
) -CommandName New-ADUser

$Password = Read-Host -assecurestring "SP2013 Farm Account Password"
$Name = "spExtranetFarm"
$UPN = ""
$Description = "SharePoint Farm Administrator Account - Extranet"
$Path = "ou=service,ou=accounts,ou=test,dc=mikefrobbins,dc=com"
New-ADUser -Name $Name -AccountPassword $Password -Description $Description `
-Enabled $true -PasswordNeverExpires $true -Path $Path -SamAccountName $Name `
-UserPrincipalName $UPN

$Password = Read-Host -assecurestring "SP2013 Install Account Password"
$Name = "spExtranetInstall"
$UPN = ""
$Description = "SharePoint Installation Account - Extranet"
$Path = "ou=service,ou=accounts,ou=test,dc=mikefrobbins,dc=com"
New-ADUser -Name $Name -AccountPassword $Password -Description $Description `
-Enabled $true -PasswordNeverExpires $true -Path $Path -SamAccountName $Name `
-UserPrincipalName $UPN

$Password = Read-Host -assecurestring "SP2013 AppPool Account Password"
$Name = "spExtranetPool"
$UPN = ""
$Description = "SharePoint Application Pool Account - Extranet"
$Path = "ou=service,ou=accounts,ou=test,dc=mikefrobbins,dc=com"
New-ADUser -Name $Name -AccountPassword $Password -Description $Description `
-Enabled $true -PasswordNeverExpires $true -Path $Path -SamAccountName $Name `
-UserPrincipalName $UPN


Add the Farm and Install accounts to the local administrators group on the server that will become the SharePoint web front-end server. In this example, I’m also running this script from the same Windows 8 workstation as the previous script and I’m taking advantage of the PowerShell remoting Invoke-Command cmdlet since I’ve previously enabled PowerShell remoting on the server named SP2013 that will become the SharePoint web front-end server. In this scenario, the server named SP2013 is running Windows Server 2008 R2 with Service Pack 1. Once again, I’ve specified the -Credential parameter since the user account I’m logged in to the workstation as and running PowerShell as is a user who has almost no rights. This allows me to specify credentials with elevated permissions that only this script will run as to maintain maximum security of this environment.

Invoke-Command -ComputerName sp2013 {
$User = [ADSI]("WinNT://mikefrobbins/spExtranetFarm")
$Group = [ADSI]("WinNT://sp2013/Administrators")
$User = [ADSI]("WinNT://mikefrobbins/spExtranetInstall")
$Group = [ADSI]("WinNT://sp2013/Administrators")
} -Credential (Get-Credential)


Add the Install account to the dbcreator and securityadmin roles on the SQL Server. I don’t have the SQL Management Studio Tools installed on the workstation this PowerShell script is being run from either so I’m going to use implicit remoting as with the prior example where I imported the New-ADUser cmdlet except this time the PSSession will be to the SQL Server and I’ll import the Invoke-Sqlcmd cmdlet. Both the domain controller and SQL Server in this environment are running Windows Server 2012 so PowerShell remoting is enabled by default on both of them.

Import-PSSession -Session (
New-PSSession -ComputerName sql01 -Credential (Get-Credential)
) -CommandName Invoke-Sqlcmd

Invoke-Sqlcmd -ServerInstance sql01 -Database masterQuery `
"USE [master]
ALTER SERVER ROLE [securityadmin] ADD MEMBER [MIKEFROBBINS\spExtranetInstall]


You can now see that the Install account is a member of those roles:


Set the “Max Degree of Parallelism” to 1 on the SQL Server:

Invoke-Sqlcmd -ServerInstance sql01 -Database masterQuery `
"EXEC sys.sp_configure N'max degree of parallelism',N'1'


Changing this setting does not require the SQL Server service to be restarted. Here’s where the setting is located at in the GUI:


If this setting is not changed, you will receive the following error later on during the initial configuration of SharePoint 2013:

New-SPConfigurationDatabase : This SQL Server instance does not have the required “max degree of parallelism” setting of 1. Database provisioning operations will continue to fail if “max degree of parallelism” is not set 1 or the current account does not have permissions to change the setting. See documentation for details on manually changing the setting. At line:7 char:1 + New-SPConfigurationDatabase -DatabaseName $DbName -DatabaseServer $DbServer -Adm … +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidData: (Microsoft.Share…urationDatabase:SPCmdletNewSPConfigurationDatabase) [New-SPConfigurationDatabase], SPException + FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletNewSPConfigurationDatabase


When you’re finished, don’t forget about removing the PSSessions. The following command will remove all PSSessions:


Login to the SharePoint Web front-end server as the Install account. Run the “SharePoint.exe” executable that was previously downloaded. Select “Install software prerequisites”:


The SharePoint server needs to have a connection to the Internet to download the prerequisites, although you could download the prerequisites from another machine and install them manually if necessary.


Once a portion of the prerequisites are installed, the server will need to reboot to continue with the prerequisites installation:


Once the server restarts, log back in with the same user account (the install account). The server will continue with the prerequisites and it will need to reboot one more time after a few more of the prerequisites are installed:


You may briefly see this command window after the restarts when you log back into the server if UAC (User Access Control) is enabled:


The prerequisites will eventually finish installing:


Now re-run the downloaded SharePoint executable and select “Install SharePoint Foundation”:


Choose the “Complete” installation type:


Select the “Data Location” tab and enter a location for the search index files. This will only be used if you enable the search service on this server, but go ahead and set it just in case:


Uncheck the “Run the SharePoint Products Configuration Wizard now” checkmark:


Test Connectivity to the SQL Server. In my blog on SharePoint 2010, I previously performed this test by adding the telnet client to the SharePoint web front-end server, but that’s really unnecessary since you can do the same thing with PowerShell and it eliminates the security risk on having the telnet client installed.

(New-Object System.Net.Sockets.TCPClient("sql01",1433)).Connected


Run the PowerShell script for the initial configuration. This is exactly the same as the script I used with SharePoint 2010.

Add-PSSnapin Microsoft.SharePoint.PowerShell
$FarmCredential = Get-Credential -credential mikefrobbins\spExtranetFarm
$Passphrase = Read-Host -assecurestring "SP PassPhrase"
$DbName = "SP_Extranet_Config"
$DbServer = ""
$AdminContentDb = "SP_Extranet_AdminContent"
New-SPConfigurationDatabase -DatabaseName $DbName -DatabaseServer $DbServer -AdministrationContentDatabaseName $AdminContentDb -FarmCredentials $FarmCredential -Passphrase $Passphrase
Install-SPHelpCollection -All
Install-SPFeature -AllExistingFeatures
New-SPCentralAdministration -Port 55000 -WindowsAuthProvider "NTLM"


Run the following PowerShell script to turn the Application Pool account into a SharePoint managed service account. This accomplishes the same thing as the way I did this in SharePoint 2010, although I’ve polished the script a little more and taken advantage of the pipeline:

Get-Credential -credential mikefrobbins\spExtranetPool | New-SPManagedAccount


Create a web application and site collection with PowerShell. There are a couple of changes that need to be made to the script that I used to accomplish this in SharePoint 2010. If you don’t use the -AuthenticationProvider parameter, you’ll receive the following warning message about the Windows Classic authentication method being deprecated in SharePoint 2013:

WARNING: The Windows Classic authentication method is deprecated in this release and the default behavior of this cmdlet, which creates Windows Classic based web application, is obsolete. It is recommended to use Claims authentication methods. You can create a web application that uses Claims authentication method by specifying the AuthenticationProvider parameter set in this cmdlet. Refer to the site for more information. Please note that the default behavior of this cmdlet is expected to change in the future release to create a Claims authentication based web application instead of a Windows Classic based web application.


The following PowerShell script creates the web application and site collection without any warnings or errors:

$WebAppPool = "SP - Extranet"
$WebAppName = "SP - Extranet"
$WebAppPoolAcct = "mikefrobbins\spExtranetPool"
$WebAppDbName = "SP_Extranet_Content"
$WebAppDbServer = ""
$WebAppPath = "D:\inetpub\wwwroot\wss\VirtualDirectories\Extranet"
$WebAppPort = "80"
$SiteColUrl = ("")
$SiteColOwner = "mikefrobbins\spExtranetFarm"
$SiteColDescription = "Mike F Robbins - Computing Solutions Extranet"
$SiteColName = "Extranet"
$SiteColTemplate = "STS#0"
New-SPWebApplication -ApplicationPool $WebAppPool -Name $WebAppName -ApplicationPoolAccount (Get-SPManagedAccount $WebAppPoolAcct) `
-DatabaseName $WebAppDbName -DatabaseServer $WebAppDbServer -Path $WebAppPath -Port $WebAppPort -Url $SiteColUrl `
-AuthenticationProvider (New-SPAuthenticationProvider)
New-SPSite -Url $SiteColUrl -OwnerAlias $SiteColOwner -Description $SiteColDescription -Name $SiteColName -Template $SiteColTemplate


Once you’ve made the necessary DNS changes, you should be able to access your new SharePoint site, right? Well, not if you’re attempting to access it from the SharePoint web front-end server itself. You’ll constantly be prompted to login and finally be denied access:


You’re experiencing this issue as documented on Microsoft TechNet. Many blogs will point you in the direction of disabling the loopback check, but as the referenced support article says, that’s the less than desirable solution.

The following PowerShell script will disable strict name checking and allow BackConnectionHostNames to the specified names:

New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters' -Name DisableStrictNameChecking -Value 1 -PropertyType "DWord"

New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -Name BackConnectionHostNames -PropertyType MultiString
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -Name BackConnectionHostNames -Value ""


Once these changes have been made, restart the IISAdmin service and you should be able to access your new SharePoint site from the web front-end server:


By installing SharePoint Foundation 2013 with PowerShell, the database names are much more meaningful than some name with a cryptic GUID on the end of it:


Looking for more information? See the Windows PowerShell for SharePoint 2013 learning roadmap.