Installation and Configuration of Sharepoint Server 2012 for

Sharepoint server 2013

Installation Preparations

The first step is to obtain your SQL Server installation media. According to the official
Microsoft SharePoint 2013 requirements document, SharePoint 2013 supports SQL
Server 2008 R2 SP1 (and later) and SQL Server 2012 RTM (and later). For this, I used
SQL Server 2012 SP1 Standard Edition. I chose SP1 for a couple of reasons. First, SP1 is
newer and more advanced than SQL Server 2012 RTM. It also won't require patching as
soon and is likely more secure and stable than the RTM version. Second, a few of
SharePoint's fancy business intelligence (BI) pieces require SP1, so having SP1 installed
will make it easier for you if you want to use those BI pieces later. I used SQL Server
2012 Standard Edition, but SharePoint works well with the other supported editions.
You can use the free Express edition or the super-cool and expensive Enterprise edition,
depending on your needs. (See the SQL Server 2012 Editions information for a list of
features provided by each SQL Server edition, including Express.)

If your SQL Server installation is an ISO image file and you're running Windows Server
2012 R2, Server 2012 R2 has some new handy functionality that will help you. You can
right-click an ISO file and simply mount it as a drive letter. You no longer need to crack
open the ISO file and copy the files out. When you're finished installing SQL Server 2012,
you just right-click your phony optical drive and click Eject. Hooray for technology!

Accounts

Before installing SQL Server 2012 SP1, I created two Active Directory (AD) accounts. I
used one account to install SQL Server; the other account is used for running the SQL
Server instance. These accounts are somewhat analogous to the spadmin and sp_farm
accounts that I recommend for SharePoint. In this case, I created the accounts spadmin
and spsql. Like spadmin, spsql is a domain account and a local administrator on the box
on which I'm installing the software.

When I installed SQL Server, I configured it to run its services as spadmin. There are
three obvious questions that you might have about the install account. First, why didn't I
just install SQL Server as spsql? Second, why didn't I install it as a domain
administrator? Finally, why didn't I install it as spadmin?
My answers to these questions are as follows. First, I didn't install SQL Server as spsql
because I prefer to do least-privilege installations, and spsql doesn't need to be, and
shouldn't be, a local administrator on the SQL Server instance. If someone interjects
some malicious or just plain shoddy code into a stored procedure, I want to limit the
damage that the code can do.

The install account, however, does need to be a local administrator. So I use a separate
local admin account to install the software. I don't use the domain administrator or an
account that's a member of the domain administrators group because once again, I like a
least-privilege model, and the installer doesn't need to be a domain admin—therefore it
doesn't get to be a domain admin. Also, if the account that installs SQL Server is a
domain admin, it will, with good intentions, make some changes to AD, including
creating a service principal name (SPN) for SQL Server. This won't immediately cause
you any issues, but if you ever switch SharePoint to use Kerberos, the SPN might be
problematic. SQL Server could possibly create an SPN that could break Kerberos
authentication for SharePoint if you ever change the service account that SQL Server
uses. Thus you're better off manually creating the SPN for SQL Server when you need it.

Having SQL Server's SPN (MSSQL/sq01.contoso.com in this case) assigned to two

accounts will absolutely break Kerberos. When it comes to troubleshooting, Kerberos is a
worthy adversary. And because you didn't create the original SPN, you'll never think to
look there. Do yourself a favor and don't let that happen. (Yes, you can use the command
setspn -X to find duplicate SPNs, but you need to know you're looking for duplicate SPNs
to use that. Kerberos is tricky that way.)

Finally, even though the requirements seem the same, I don't install SQL Server as
spadmin. When we configure our SharePoint farm, we will do so as spadmin. If the
account that creates the SharePoint farm has elevated permissions in SQL Server, the
account will try to make some changes to the farm. Namely the account will change the
max degree of parallelism option (MAXDOP) to 1. Although that particular change isn't a
bad thing, I don't like the idea of SharePoint making changes to SQL Server that I don't
know about. Plus, that least-privilege principle comes up again. The spadmin account
doesn't need to be a local admin on the SQL Server box, so it doesn't get to be.

If you don't like having a lingering account that's a local admin on your SQL Server box
(and who does?), you can disable the account after SQL Server is installed and
configured. Don't delete the account, though, because you should use it later when you
patch your SQL Server system. If you have multiple SQL Server instances in your
organization, I recommend using a different pair of spadmin and spsql accounts for each
instance. You don't want to accidentally break someone else's SQL Server instance. Even
worse, you don't want another SQL Server DBA accidentally breaking yours. It happens
all too often.

The Setup

After you've downloaded and mounted the media and created your accounts, log in as
spadmin and run setup.exe at the root of the drive. Doing so will launch an installer.
Much like SharePoint, SQL Server has a splash screen and installer, but unlike
SharePoint, SQL Server's installer resembles a labyrinthine maze. When the installer
comes up, click Installation at the left to display the installation options. For our sample
installation, I clicked New SQL Server stand-alone installation or add features to an
existing installation, as shown in Below figure 1. Setup will then run some checks on the
machine, such as making sure that your install account has adequate permissions and
that the correct .NET Framework versions are installed. If your machine has any issues
here, make sure you fix them. Then click OK to move on.

SQL Server Installation Center

The next screen has you enter your license key or run SQL Server in a trial mode.
SharePoint will run just fine if SQL Server is in trial mode, right up to the moment that
the trial ends. That's not a fun phone call to take and not a fun problem to troubleshoot
or fix. If you have a legitimate SQL Server license, now is the time to enter it. Then click
Next.

In the next step, Setup will check to see whether any important SQL Server updates
should be installed. Unless there's a compelling reason not to, install any patches that
Setup recommends, then click next. The SQL Server installation process will install a
very helpful patch that fixes a nasty MsiInstaller bug that was introduced in SP1.
Allowing the installer to install patches will save you a lot of time later on.
Once you're past the update step, Setup will install some installation files and run some
more checks. If there are any issues to fix, tend to them and click next. If your SQL
Server system doesn't have Internet access, Setup might stall a bit at this point. Don't
worry about that; after the requests time out, Setup will continue.

The next screen (Below figure 2) will ask you whether you want to install individual
features or all features with the defaults. We will choose the SQL Server Feature
Installation option, so that we can customize our installation with the SQL Server
features specifically needed for SharePoint.

SQL Server 2012 Setup Screen

The Features

After selecting SQL Server Feature Installation and clicking next, a list of SQL Server
features is displayed, as shown in Below figure 3. We really need only one SQL Server
feature for SharePoint: Database Engine Services. However, I will also install the
Management Tools (Complete) feature, which gives you handy tools such as SQL Server
Management Studio. As you browse through the list of features, you might be tempted to
check more features than you really need. But unless you're going to use a particular
feature immediately, I don't recommend installing it. If you want to add a feature later,
such as SQL Server Reporting Services, you can just run Setup again and add the feature
to your existing instance. After selecting the features, leave the feature directories as they
appear in the dialog and click next.
Selecting SQL Server Features to Install

Click Next again until you reach the Instance Configuration screen. In this example, we'll
install SQL Server to the default instance. When we reference the default instance, it's
just the server name, so that's easy to keep track of. Internally SQL Server calls the
default instance MSSQLSERVER. In this installation, we'll go ahead and install the
binaries on the C drive, as shown in below figure.

Configuring a SQL Server 2012 Instance

Click Next. The next screen will display the drive space requirements for each drive.
After you review that information, click next again. You'll see the Server Configuration
screen, shown in below, where you will set the SQL Server service account names and
passwords.

Setting the SQL Server Service Account Names and Passwords

Accounts Again

We'll use the spsql account. This account doesn't need any elevated privileges in either
AD or on the SQL Server instance. The account we're using for installing SQL Server will
take care of all that. Use the spsql account for both the SQL Server Agent and the SQL
Server Database Engine. If you want to get fancy, you could run the Agent as a different
account, but that isn't necessary. You don't need to make any changes to the Collation
tab. In previous versions of SharePoint and SQL Server, the collation had to be set very
specifically. That's no longer the case. Technological advances save the day again.

Click Next to advance to the Database Engine Configuration screen, shown in Below
figure 6, where you'll set up authentication. The default authentication mode is Windows
authentication, and we're fine with that. However, we do want to add an account
underSpecify SQL Server administrators at the bottom of the screen. This account will
be our back-door account in case we need to get into SQL Server to do some
management. The account will have unrestricted access to SQL Server, so it should be a
highly guarded account. In the past, I've used something like the Domain Admin or
spadmin account. This account should be necessary only for emergencies.
Setting Up SQL Server Authentication

Here you can add additional services accounts that are created for the purpose of installation and
configuration of sharepoint server 2013.

Location, Location, Location

Now click the Data Directories tab to set the location where SQL Server will store various
files. This gets into one of the trickier bits of a SQL Server installation. There's a lot of
guidance available on how you should lay out the files for a SQL Server instance.
However, following that guidance can be expensive. Ideally the operating system,
TempDB, your data files, your log files, and your backups would all be on separate
spindles. That's five different drive locations. You'll also want those drives to be fault
tolerant, so that's a minimum of 10 disks. In some situations, that layout is feasible, but
in general having all the recommended disks would be too costly to be practical.

Keeping those SQL Server file types separated will improve both performance and
reliability. In many cases, the database engine is writing from one of those file types to
another. If the different types of files are on separate spindles, the read and write
operations aren't fighting against each other for the drive's attention. Separating them
will increase reliability by keeping one file type from filling up the drive that the other
file types are on. You can't kill SQL Server because your backups filled up your data
drive, for instance. Or, one of SQL Server's favorite tricks is to let one of the log (.ldf) files
fill up a drive, usually the C drive, thus collapsing the entire SQL Server instance. Putting
the .ldf files on their own drive keeps that from happening.

The layout in Below figure 7 shows a best-case scenario, with the exception of TempDB,
which I forgot to move. All of those locations can be changed after installation, but it's
easiest to lay out the files correctly at installation time.

Best-Case-Scenario Layout for Database Engine in SQL Server 2012

The Grand Finale

I know there have been a lot of screens so far, and a dizzying amount of clicking Next.
Don't fret, we're almost at the end of the installation process. After we click Next a couple
more times, we'll see the screen in Below figure 8, which provides a summary of the
install decisions we've made so far.
Verifying the SQL Server 2012 Features to Be Installed

This screen has a hidden gem at the bottom: a configuration file path. Without us even
asking, SQL Server generated a ConfigurationFile.ini that saved all our configuration
options. This file can be used as immediate documentation of your SQL Server instance,
and it can be used to install another instance with the same settings. Because this is just
a text file, you can open it and tweak it however you'd like for your next install. To install
SQL Server using a ConfigurationFile.ini, you have to run setup.exe from a command
prompt (alternatively, you could use Windows PowerShell) and pass the file location as a
parameter.

At this point you have two things left to do. The first is to click Install and watch the
magic happen. The second is to lean back and admire your handiwork. Although SQL
Server won't give you a gold star for a job well done, it will give you a happy screen like
the one in Below figure 9 verifying that your installation was successful.
If you've followed the process described in this article, you'll soon be rewarded with a
solid SQL Server installation that you can show your friends, and one that should work
well for any SharePoint farm. Installing is only half (though arguably the largest half) of
what you need to do, though. After the SQL Server instance is installed, you still need to
do some configuration before it's ready for SharePoint.

Configure SQL Server 2012 for SharePoint 2013

I discuss the two configuration steps that you must perform to enable SQL Server as a
SharePoint database server.

Setting up Maximum Degree of Parallelism to 1 (If it’s already set to 1. Ignore this)

We installed a SQL Server instance, but there are a few tweaks we need to make before
that instance can work with your SharePoint 2013 setup. To perform these tweaks, your
first step is to log into SQL Server as an account that has elevated permissions to the SQL
Server instance. I logged in and made the tweaks via the spadmin account that I used to
install SQL Server.
After SQL Server is installed, open SQL Server Management Studio (SSMS). With the
exception of the last tweak I suggest, all the changes are made to the SQL Server
instance. To access the instance's settings, right-click the instance name and click
Properties from the flyout menu.

The first change I make after SQL Server 2012 is installed is to set the max degree of
parallelism option (MAXDOP) to 1—a setting that is a requirement for creating the
SharePoint 2013 farm. This required setting is new in SharePoint 2013; in SharePoint
2010 setting MAXDOP to 1 was only recommended. By default MAXDOP is set to 0,
which tells SQL Server, "Parallelize as much as your bad self wants to." To change the
setting to 1, in the properties for the SQL Server instance, go to the Advanced tab. You'll
find the MAXDOP option under the Parallelism group, as shown in Below figure 1. Set it
to 1 and click OK.

Setting Max Degree of Parallelism to 1 in SQL Server 2012

What exactly is MAXDOP, anyway, and why is it so important to SharePoint? MAXDOP
is a setting that defines how many CPUs SQL Server uses when it's executing a query.
That's great, if the queries were written to take advantage of that setting. If they weren't,
splitting the execution among multiple processors can have unpredictable results.
Unpredictable is acceptable for birthday presents, or the ending to O. Henry stories, but
it isn't so good for SharePoint. SharePoint is unpredictable enough on its own without
SQL Server pitching in. Because SharePoint's stored procedures were not all written to
handle parallelism, MAXDOP has to be 1.

Fine-Tune Your SQL Server 2012 Configuration for SharePoint 2013

Set Maximum Amount of SQL Server RAM

One optional tweak I like to make to my SQL Server 2012 configuration for SharePoint
2013 is to set the maximum amount of RAM that the SQL Server database engine can
use. SQL Server is usually pretty good at sharing RAM and managing memory in general.
If you've ever looked at the memory usage on a SQL Server box, you'll see that SQL
Server is using almost all the memory on the box. This is really a good thing. You don't
want any unused RAM lying around, not if SQL Server can use it to cache things and give
better performance. SQL Server is a good neighbour, though, and if other programs want
some memory, SQL Server will free up some memory for them—most of the time.

Once in a while, SQL Server doesn't release RAM as it's supposed to. This happens pretty
infrequently, but when it does happen, it's a huge pain. This usually means the server is
running very slowly and remote tools can't get in to fix anything. To keep this from
happening, I usually set the maximum amount of RAM that SQL Server can use, as
shown in below figure.
Setting the Maximum Amount of RAM That SQL Server Can Use

There are probably better guidelines available, but on a typical server today that has
32GB or 64GB of RAM, I usually make the maximum amount of RAM around 90 percent
of the system RAM. That leaves 10 percent or so, which should be enough for the
operating system, backup software, and other essentials. If you have other SQL Server
instances or SQL Server components (such as SQL Server Reporting Services) installed
on the same server, make sure to adjust your headroom accordingly. The server in the
video accompanying this article has 16GB, so I gave SQL Server roughly 12GB.

This setting is very intuitively on the Memory page of the instance settings. The
important part is that I leave enough for the OS to let me in via Remote Desktop Protocol
(RDP) if I need to access SQL Server remotely to address the problem.

Opt for Compressed Backups

Compressing backups is another optional configuration setting I enable when

configuring a new SQL Server instance. When you enable backup compression, your
database backups will be compressed when native SQL Server backups are executed. An
additional benefit is that the backups will also be compressed if you do a farm-level
backup in SharePoint. Backups on your SQL Server system probably happen at times
when the workload is lighter—when there are CPU cycles sitting around looking for
something to do. Using those spare CPU cycles to compress your backups will make
them take up less space and get the backup done faster, too.
How do you make all this magic happen? Open the properties of the SQL Server instance
and navigate to the Database Settings page, shown in below figure.

Enabling Compressed Backups

Select the Compress backup check box. Doing so sets the default for the instance. Note
that when you back up a database, you can still manually specify whether or not the
backup will be compressed. Also notice that the page shown in Below figure 2 is where
you set the default locations for databases, log files, and database backups. We set these
defaults during the install, but if you want to change them, this is where you'd do it.
Changing a default setting only impacts databases that are created after you change the
setting. It won't magically move your existing databases for you.
Set the model Database's Recovery Model

There's one final optional tweak I make before I turn SQL Server over to SharePoint,
especially if it isn't a production environment. I set the model database's recovery model
to Simple. This setting tells SQL Server to overwrite transactions in the transaction logs
that have been committed to the database files. This keeps those sneaky .ldf files from
filling up your drive and taking down SQL Server. No one has time for that.

Just as you can set the default behavior for backup compression, you can set SQL
Server's default recovery model behavior. SQL Server has a database called model that it
uses if certain settings aren't defined when a database is created. The Recovery
model setting is one of those settings. If a database doesn't have the Recovery
model setting defined when it's created, then that database will get whatever options the
model database has. Of course you can change the options for your database later if you
want to. You will not want the Simple recovery model if you start using some high-
availability functionality such as mirroring or AlwaysOn Availability Groups. If you
decide to use any of those features later, you'll have to switch the Recovery Model setting
back to Full.

To set the recovery model, find the model database under System Databases in Object
Explorer. Right-click the model database and open its properties. On the options page,
shown in below figure, you'll find the Recovery model setting options. Select Simple
from the drop-down list and click OK.
Setting the model Database's Recovery Model to Simple

Again, you can change this setting at any time both on individual databases and on the
model database itself. Not all SharePoint's databases inherit their recovery model setting
from model, so you'll need to keep a watchful eye on those .ldf files, even if you set the
model database recovery model to Simple.

Following the setup and configuration guidance I've provided in this article series will
help to ensure that your SQL Server 2012 instance works smoothly and reliably for your
SharePoint 2013 farm. Check out the list at the end of this article for links to the other
articles in the series, plus additional helpful resources.