Service accounts and dependencies
TFS 2015
You can better manage Azure DevOps Server if you understand the services and several service accounts that every deployment of Azure DevOps includes and on which every deployment depends. Depending on how you have installed and configured Azure DevOps, these services and service accounts might all run on one computer, or they might run on many computers. This changes certain aspects of managing your deployment. For example, if the server-side components of your deployment run on more than one computer, you must ensure that the service accounts your deployment uses have the access and permissions they require to function correctly.
Azure DevOps Server has services and service accounts that run on the following computers in a deployment:
- any server that hosts one or more databases for Azure DevOps Server
- any server that hosts components of the application tier for Azure DevOps Server
- any computer that is running Azure DevOps Server Proxy
- any build computer
- any test machine
You can install and deploy different features of Azure DevOps Server in various ways. The distribution of features in your deployment determines what services and service accounts run on which physical computers. In addition, you might need to manage the service accounts for software programs that are configured to work with Azure DevOps Server, such as the service accounts for SQL Server.
Service accounts
Although Azure DevOps Server uses several service accounts, you can use the same domain or workgroup account for most or all of them. For example, you can use the same domain account Contoso\\Example as both the service account for Azure DevOps Server (TFSService) and the data sources account for SQL Server Reporting Services (TFSReports). However, different service accounts can require different permission levels. For example, TFSService must have the Log on as a service permission, and TFSReports must have the Allow log on locally permission. If you use the same account Contoso\\Example for both, you must grant both of these permissions to it. In addition, TFSService requires significantly more permissions to operate correctly than those that TFSReports requires, as the table later in this topic shows. For security purposes, you should consider using separate accounts for these two service accounts.
Important
You must not use the account that was used to install Azure DevOps Server as the account for either of these service accounts.
If you have deployed Azure DevOps Server in an Active Directory domain, you should set the Account is sensitive and cannot be delegated option for service accounts. For example, in the following table, you should set that option for TFSService. For more information about required service accounts and placeholder names used in documentation for Azure DevOps Server see the topic "Accounts required for installation of Azure DevOps Server" in the installation guide for Team Foundation. For more information about account delegation in Active Directory, see the following page on the Microsoft Web site: Delegating Authority in Active Directory.
Because you must manage several service accounts, each service account is referred to by a placeholder name that identifies its function, as listed in the table later in this topic. The placeholder name is not the actual name of the account that you use for each service account. The actual name of the account varies depending on your deployment. In the previous example, the account used for both TFSService and TFSReports was Contoso\\Example. In your own deployment, you might create domain accounts with the specific names of TFSService and TFSReports, or you might use the system account Network Service as the service account for Team Foundation Server.
Important
Unless specifically stated otherwise, no groups or accounts in the following table should be members of the Administrators group on any of the servers in your deployment of Azure DevOps Server.
The following table lists most of the service accounts that might be used in a deployment of Azure DevOps Server. For additional service accounts not listed here, see Permissions and groups, Service accounts.
Service account for
Placeholder name and usable account type
Required Permission and Group Membership
Notes
Azure DevOps Server
TFSService: can be a local account, a domain account, Local Service in a workgroup, or Network Service in a domain
Log on as a service on the application-tier server
This service account is used for all of the Azure DevOps web services. If you use a domain account for this account, it must be a member of a domain that all computers throughout the deployment fully trust.
Team Foundation Build
TFSBuild, which can be a local account, a domain account, or Local Service in a workgroup
Log on as a service
This service account is used when builds are configured and when build status information is communicated between the build controller and the build agents.
SQL Server Reporting Services
TFSReports, which can be a local account, a domain account, or Local Service in a workgroup
Allow log on locally on the application-tier server and on the server that is running SQL Server Reporting Services
TFSWareHouseDataReader on the report server
This service account retrieves data for reports from Reporting Services.
Azure DevOps Server Proxy
TFSProxy, which can be a local account, a domain account, Local Service in a workgroup, or Network Service in a domain
Log on as a service
Used for all of the proxy services. If you use a domain account for this account, it must be a member of a domain that all computers throughout the deployment fully trust.
Test Agent and Test Agent Controller
TFSTest: can be a local account, a domain account, or Network Service in a domain.
Log on as a service
Used when information about tests is communicated between the test agent controller and the test agent.
SharePoint Web applications
WebAppService
Allow log on locally
You must add at least one service account for each SharePoint Web application that you configure for use with Team Foundation Server. This service account is used to create project portals and to enable dashboard functionality. You can integrate your deployment with SharePoint Products without this permission, but you must perform additional steps if the service account is not a member of the Farm Administrators group. For more information, see Integrate Team Foundation Server with SharePoint Products Without Administrative Permissions.
Lab Management
TFSLab, which can be a local account, a domain account, Local Service in a workgroup, or Network Service in a domain
Log on as a service
This service account is used when information about Lab Management is communicated between Team Foundation Server and the lab agent that is running on a virtual machine.
Services that run under service accounts
The following table lists the services that run under service accounts in an on-premises Azure DevOps deployment.
| Service name | Service account | Logical Tier |
|---|---|---|
| Code Coverage Service | TFSService | application tier |
| Azure DevOps Server Web Services | TFSService | application tier |
| SQL Server Reporting Services (MSSQLSERVER or InstanceName if using a named instance) | Local System or a domain account | application tier |
| Report Web Service | Local System, Network Service, or a domain account | application tier |
| SharePoint Administration (if SharePoint Products is installed and configured for use with Team Foundation Server) | Local System, Network Service, or a domain account | application tier |
| SharePoint Timer (if SharePoint Products is installed and configured for use with Team Foundation Server) | Domain account | application tier |
| Visual Studio Team Foundation Build Service Host (if Team Foundation Build is installed) | TFSBuild | build computer |
| Visual Studio Team Foundation Background Job Agent | TFSService | application tier |
| Visual Studio Test Controller | TFSTest | any computer |
| Visual Studio Test Agent | TFSTest | test computer |
| Analysis Server (MSSQLSERVER or InstanceName if you are using a named instance) | Local System or a domain account | data tier |
| SQL Server Browser | Local Service or a domain account | data tier |
| SQL Server (MSSQLSERVER or InstanceName if using a named instance) | Local System, Network Service, or a domain account | data tier |
| SQL Server Agent (MSSQLSERVER or InstanceName if using a named instance) | Local System, Network Service, or a domain account | data tier |
| Account Service (CollectionName) | Automatic | web tier (Azure DevOps Services only) |
For more information about service accounts for SQL Server, see the following page on the Microsoft Web site: SQL Server Books Online.
Note
If you change the service account for Team Foundation Build, you must make sure that the new service account is a member of the Build Services group. You must also make sure that the account has read/write permissions to the temporary folders and the ASP.NET temporary folder. Similarly, if you change the service account for the Team Foundation Server Proxy service, you must make sure that the account is a member of the appropriate groups. For more information, see Configure Your Build System.
Q & A
Q: Are service accounts assigned to an access level group?
A: By default service accounts are added to the default access level. If you make Stakeholder the default access level, you must add the Azure DevOps Server service account to the Basic or Advanced group.
Q: Do service accounts require a license?
A: No. Service accounts don't require a separate license.
Q: How do I change the password or account for a service account?
A: See Change the service account or password