Datasheet

CHAPTER 1 SharePoint Foundation 2010 under the hood

Local users and groups will be used to give users access to SharePoint in that scenario, rather than

going through a domain controller. You can still support incoming email in that scenario by enabling

SMTP in IIS and then setting it up in Central Administration.

It just goes to show that SharePoint is scalable down as well as up.

Setup Account (Complete Install) In a domain server farm install, the setup account

should be a domain admin (you can use local administrator accounts to install SharePoint

on each individual server, but it is easier simply to use one setup account that is a domain

admin). This account should be allowed to install SharePoint on any server in the domain,

and it must be able to access the SQL server that SharePoint will be using to build databases.

On the SQL server, the setup account must have these SQL server security roles on the target

SQL server: Login, SecurityAdmin, and DBCreator.

Farm Account Also known as the conﬁguration database account, this account is powerful

and critical to SharePoint. It does not need to have administrative privileges, but it should

be a domain account. All other rights for this account will be conﬁgured automatically by

the setup account during installation. The setup account adds the farm account to the SQL

server’s Logins, DBCreator, and SecurityAdmin roles. This is why the farm account ends up

being the owner (DBO) of most of the SharePoint databases.

This account is the Central Administration application pool identity. This means that it is the

account that accesses and changes the conﬁguration database for the server farm. It is also

the account used to power the SharePoint Timer service, which is in charge of any jobs that

need to be started and stopped at different times (such as getting incoming mail, managing

quotas, and managing alerts). This account should be guarded and not used for anything

else (except for the one rare occasion of setting up a super-admin account in PowerShell).

The DBO Exception

Oddly enough, the farm account does not become the DBO of the conﬁguration database for the

server farm, because the setup account creates that database during installation and then assigns

ownership of it to the database access account. This means that, by default, the setup account is the

DBO, but the farm account holds an owner role. This also means that, in a pinch, the setup account

can be used to do farm administration in PowerShell, if necessary.

Content Database Access Account Also known as the content database account, web applica-

tion account, or web application application pool account, this is the account that uses the content

database(s) of a web application. There should be one of these per web application—although

under some circumstances (as is the case in businesses with security policies that limit ser-

vice accounts), web applications can share an account. This account should be a domain user

and otherwise is given (and requires) database ownership of all content databases associated

with the web application it is working for.

If you are going to have more than one web application, you may want to consider creating a

content database access account for each of them. This helps give the account least privilege

(if it is compromised, it can only affect that web application; if it fails, it causes only one web

application to fail), and it is easier to troubleshoot if each web application has its own content

626382c01.indd 16 1/27/11 10:47:23 AM