Microsoft Office Tutorials and References
In Depth Information
SharePoint Foundation now supports managing accounts. Not only can it sense and adapt to any
change in the passwords of its managed accounts, but it can be configured to generate a random,
strong password for its accounts itself—either on a schedule you set or a certain number of days
before the domain’s password expiration policy deadline. It can also just send you an email warning
of an impending change, as well as a warning if it does not succeed with a password change.
Keep this in mind when creating your service accounts. It is usually standard procedure to create
the domain user accounts with the password policy set to never expire, and the user can’t change
their password. Now, depending on the domain’s password policies, that is a less important issue.
In the case of accounts you plan to have SharePoint manage, it is a good idea to set passwords so
that the user isn’t obligated to change them upon login, but that the password does expire and the
user can change them. Most of the accounts that SharePoint will use to manage services or access
databases will be required to be registered as managed accounts before they can be used.
Farm Account This account is the one used by all SharePoint servers in the farm to access
the farm’s configuration database and run SharePoint-specific services; it is added as an owner
of the configuration database during installation. It will create all the other databases used by
SharePoint, add the necessary accounts to SQL and give them the correct database access, as
well as add accounts to the appropriate SharePoint related groups on the SharePoint servers. It
also is the SharePoint Timer service account (as well as the Workflow Timer) and the application
pool identity for Central Administration. The simple domain user account I created for this
purpose is spffarm. This account is added during installation as a managed account, but by default,
SharePoint does not do anything with its password. This account is also the only one that, by
default, is able to use PowerShell to manage everything when SharePoint is installed in a farm
configuration. For more about PowerShell, see Chapter 14, “STSADM and PowerShell.”
Search Account This account is one of the owners of the Search database, and it answers
Search queries. My account for this one is spfsearch This account is required to be registered .
as a managed account.
Index Account This account is one of the owners of the Search database and is
otherwise known as a content access account, crawler, gatherer, or indexer. It crawls and indexes
SharePoint content. It must have read access to all Search-enabled content databases. I’ll
be using spindex for this account. Interestingly, it doesn’t need to be set up as a managed
account before it is used.
Content Database Account This account owns and accesses the content database of a web
application, such as the first SharePoint site. For this account, I’ll be using spfcontent . This
account is required to be a managed account. In some environments, you might want to
consider using a different content database account for each of your web applications, especially
since accounts can be managed by SharePoint. In this topic, additional web applications will
be created, and will be using their own content database accounts. For more about that, see
Chapter 10, “Site Collections and Web Applications.”
“I WANNA HOLD YOUR HAND...”
Please take note of the account names I am using for these services, because you will see them
throughout the entire book. The Complete installation built in this chapter will be used in hands-on
examples for the rest of this topic. If you substitute your own account names here, be sure to use
those same account names when you see my corresponding names in later chapters.