Microsoft Office Tutorials and References
In Depth Information
BDC Account This account is the one used by SharePoint to pass data back and forth between
a user (accessing an external list or external lookup field), SharePoint, and an external data
source (often a non-SharePoint SQL database) using the Business Data Connectivity service.
BDC supports claims-based authentication, and it can use its own credentials or pass through
the user’s credentials to access external data (however, that requires the user to have the right
to directly access the external database). Often the BDC uses the farm account as its identity,
but it is not a bad idea to create a unique account for this service. Keep in mind that this service
is optional, if you don’t plan to use it, you don’t need to configure it. For this account, I am using
spfbdc . This is another account that must be managed.
Sandboxed Code Service Account This service is used by SharePoint to manage solutions
that are deployed in a “sandboxed” fashion, not to the whole farm but to a single site collection
with restrictions on the resources it can use. These sandboxed solutions (sometimes known
as user solutions ) don’t require farm administration permissions but can be uploaded to a site
collection and activated by a site collection administrator (or site owner). However, activation
won’t work unless the Sandboxed Code service is started. When it starts, it will use the farm
account by default, despite the fact that it will trigger errors and is not recommended. It is
suggested you use a different domain account for the service instead. This service is optional and
doesn’t need to be enabled if you are not going to deploy sandboxed solutions. For this account,
I am using spfusrcode . This is another account that must be managed.
Remember that defining these accounts is necessary only if SQL and SharePoint are going to
run on different servers. However, it is considered good practice to use separate accounts if you
are going to have other servers running SharePoint on the farm to support user requests.
IF YOU’RE CONSIDERING POWERSHELL
If you are going to use an account to do work in PowerShell, it will need to be a shell admin, which
means they will have the dbowner fixed role in SQL for each database on the farm you will use the
account to manage, and be a member of the WSS_Admin_WPG group on the SharePoint servers.
Consider creating a domain security group for this process, to avoid having to configure individual
accounts. See Chapter 14 for details.
When SharePoint initially installs, someone needs to configure it. Therefore, when Central
Administration (the first SharePoint site made so that you can further configure and manage
SharePoint) is created, the setup account and (just in case) the built-in Administrators group are
added as farm administrators by default. Farm administrators are users added to the Central
Administration site for the purpose of administering SharePoint. (They are called farm
administrators even if SharePoint is installed on only one server.) You can add additional users to
Central Administration to be authorized as farm administrators (or remove them) as needed.
When you create other site collections, they do not have these accounts available for login by
default, so you must specify the primary and secondary administrators for the site before the
site is created. At that point, to get into the site, you must log in with one of those accounts (the
primary is obviously required, and the secondary generally isn’t).