SharePoint is a complex product that requires smart configurations. Learn about service account prerequisites and how to get going with fewer troubles.
- [Instructor] At this point, you should have a good idea as to what roles your SharePoint server or servers will have, what their hardware requirements are, as well as the necessary operating systems and version of SQL SharePoint needs. Now it's time to prepare for install. To start, there are some domain user accounts that need to be created and given specific permissions for SharePoint's sake. SharePoint is meant to access resources on separate servers on the domain, and to serve webpages to clients.
This means that SharePoint services require accounts to act as their service identity when making requests across the network or running web applications. It's also why SharePoint needs to be installed on servers that are members of a domain. The account you use to install SharePoint can be called either the setup account or the install account. This account has to be able to login as an administrator on the SharePoint servers to add roles and services. The account could be in the domain admins group, but it is best practice to add it as a local administrator to the SharePoint server specifically.
It also needs to have a SQL Server login, and have the dbcreator and securityadmin roles. In addition to the setup account, SharePoint critically depends on a domain user account that's commonly called the SharePoint farm account. This is what the setup account will assign to run SharePoint. It will add it to the correct groups on the SharePoint server, as well as add the account to the logins in SQL during installation, and make it the owner of the configuration database for the farm, and the database for the central administration site that houses the configuration UI for administrators.
The farm account runs SharePoint and is responsible for creating and configuring all of the rest of the databases that SharePoint uses. After you use the setup account to install SharePoint prerequisites, and SharePoint itself, the setup account should not be used for anything else. Keep it secure, and it should go without saying that you should never login to a server using the farm account except for one or two rare occasions in order to configure one of the service applications on the SharePoint server.
Because you should not be logging into SharePoint or anywhere else in your domain, with the setup account except when installing SharePoint, it's recommended that you also create a SharePoint admin account. This will be the account you administer SharePoint with. This account should have administrative rights to the SharePoint servers, farm admin rights to the farm, and the right to manage SharePoint using PowerShell, which can include needing dbowner rights to all the SharePoint databases in SQL.
Just to be clear, SharePoint sites are contained in SharePoint web applications. SharePoint web applications are essentially IIS websites, which use an application pool identity context to function in. Any service applications which map to IIS web applications, like search or managed metadata, will also need at least one service account to function, and in the case of search for example, the service application might actually run more than one service, and therefore need more than one acconut.
When you plan for service accounts, you can consider having one service account to be used by all service applications, and one service account to be used by all web applications. This can save on server resources. However, you can have service accounts for each web and service application to make it easier to troubleshoot, or to protect from a single account being a source of failure. That choice can vary depending on your environment. For this course, as an example, we will be setting up a single web application account and have a single service application account available as a managed account.
There are occasional additional accounts required that are not well documented, such as the super reader and super user accounts for object caching. SharePoint caches some object information on the web front-end servers for increased performance, particularly when using the publishing features, and the object cache requires two accounts. The super reader with full read permissions, and super user with full control permissions to the web applications on the farm. These accounts are easy to setup and do not need to be managed accounts.
For more, see the link for my favorite source of an easy to read list of suggested service accounts. When preparing for the accounts SharePoint requires, keep in mind that SharePoint needs accounts to be added as managed accounts on the farm before they can be used to configure web applications and service applications. With only a few exceptions. This is one of those steps people forget, so be prepared for it when we finish installation and start doing the initial farm configuration.
CA Callahan takes you through each stage of the process, covering everything from software installation prerequisites, to common topologies and MinRoles, to how to slipstream updates into an installation. Callahan introduces best practices, as well as steps involved in configuring outgoing email, web applications, site collections, managed accounts, and farm accounts. Plus, discover how to use some common tools that experienced administrators use on a day-to-day basis to make the most of their installation efforts.
- SharePoint installation considerations
- Configuring SQL for SharePoint
- Software installation prerequisites
- Using the Installation Wizard
- Installing SharePoint 2016 on additional servers
- Configuring outgoing email
- Configuring a web application and site collection