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:

sp2013-1

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:

sp2013-2

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 mikefrobbins.com 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.

sp2013-3

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.

sp2013-4

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.

sp2013-14a

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

sp2010-install6

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

sp2010-install61

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

sp2010-install62

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:SPCmdletNewSPConfig
urationDatabase) [New-SPConfigurationDatabase], SPException
+ FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletNewSPConfigurationDatabase

sp2010-install63

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

appassure123-6

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

sp2013-5

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.

sp2013-6

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

sp2013-7

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:

sp2013-8

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

sp2013-81

The prerequisites will eventually finish installing:

sp2013-9

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

sp2013-10

Choose the “Complete” installation type:

sp2013-11

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:

sp2013-12

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

sp2013-13

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.

sp2013-15a

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

sp2013-16

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:

sp2013-17

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 http://go.microsoft.com/fwlink/?LinkId=234549 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.

sp2013-171

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

sp2013-18

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:

sp2013-19

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:

sp2013-20a

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:

sp2013-21

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:

sp2013-22

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

µ

3 Comments

  1. Emanuel

    Great work Mike! It works like a charm!

    Reply
  2. Jean-Christophe

    Hi Mike,

    Very good post! I like the way how you use PowerShell. Thanks.

    ** Question **
    Though I have never experienced the issue myself, loads of administrators ran with an important issue with UPS when they had set up a FQDN for the database server name on SharePoint 2010.

    Links about the subject :
    ———————————————————————————————————————-
    http://www.harbar.net/articles/sp2010ups2.aspx#ups12
    http://blogs.technet.com/b/meamcs/archive/2010/12/01/never-again-never-use-a-fqdn-for-the-sharepoint-2010-sql-server-name.aspx
    ———————————————————————————————————————-

    I see that you use a FQDN in your script; “sql01.mikefrobbins.com”. Have you never had any problem with UPS?
    Can you confirm that this issue has been fixed on SharePoint 2013?

    Cheers.

    Reply
  3. Stephen harrington

    Mike,

    Thank You!!! I’ve been going through script after script, tech-net article after tech-net article trying to just find the basics of creating a SharePoint farm with powershell, and it hasn’t been easy. Everyone get’s so crazy and complex that it becomes impossible to follow…and unless you’re just willing to blindly run there script (which I’m not) then you pretty much out of luck. Until now, when I came across your blog. Your explanations and scripts were extremely well explained and straight forward enough that a novice like myself could understand what commands need to be run and what the outcome of those commands are. Thanks to you I can confidently say I will be able to stand-up a Home SharePoint Farm (kind of a big deal for me). Can’t say enough how much I appreciated reading your blog. I have already bookmarked your site will be returning for more of your expertise.

    Thanks,

    Stephen

    Reply

Leave a Reply

%d bloggers like this: