Prepare for Installation

This topic, the first part of the Single-Server Installation tutorial, teaches you how to create groups to manage users across Team Foundation Server, SharePoint Foundation 2010, and SQL Server Reporting Services. You'll also learn what kinds of accounts can be used as service accounts in the deployment, so that you can create these accounts, if necessary, before beginning the installation process.

The examples in this tutorial topic follow Jill Frank, an IT Administrator at the fictitious Fabrikam Fiber company, as she installs and deploys Team Foundation Server in a single-server configuration in order to support her software development teams.

In this topic

• Users, groups, and permissions in Team Foundation Server deployments

  • To create a group in Active Directory

  • To create a local group on the server

  • To create an account to use as a service account in Active Directory

  • To create a local account to use as the service account on the server

Required permissions

To perform the procedures in this tutorial, you must be a member of these groups:

• The Administrators security group on the server where you intend to install Team Foundation Server.

• The Account Operators, Domain Admins, or Enterprise Admins group, or have the equivalent permissions in Active Directory Domain Services, if you intend to create Active Directory groups to manage the users in your deployment, or use an Active Directory account as a service account. Also, if you intend to use managed service accounts as part of the deployment, you might require further permissions and additional software to create that managed service account. For more information, see Service Accounts Step-by-Step Guide.

Users, groups, and permissions in Team Foundation Server deployments

Team Foundation Server, SharePoint Products, and SQL Server Reporting Services all maintain their own information about groups, users, and permissions. To make managing users and permissions across these programs simpler, you can create groups of users with similar access requirements in the deployment, give those groups appropriate access in the different software programs, and then just add or remove users from a group as needed. This is much easier than maintaining individual users or groups of users separately in three separate programs.

If your server is in an Active Directory domain, one option is to create specific Active Directory groups to manage your users, like a group of developers and testers for all projects in the team project collection, or a group of users who can create and administer projects in the collection. Similarly, you can create an Active Directory account for services that can't be configured to use the Network Service system account as the service account. To do so, create an Active Directory account for SharePoint Foundation 2010 and as the read-access data source account for reports in SQL Server Reporting Services.

Tip

In the example deployment, Jill chooses to use the Network Service system account as the service account for Team Foundation Server and SQL Server 2008. This is the default choice. If you want to use a specific account as the service account for security purposes or other reasons, you can. Jill also creates a specific Active Directory account to use as the service account for SharePoint Foundation 2010 and as the data source reader account for SQL Server Reporting Services. She names this account SVCSPTRS.

If your server is in an Active Directory domain but you don't have permissions to create Active Directory groups or accounts, or if you're installing your server in a workgroup instead of a domain, you can create and use local groups to manage users across SQL Server 2008, SharePoint Foundation 2010, and Team Foundation Server. Similarly, you can create a local account to use as the service account. However, keep in mind that local groups and accounts are not as robust as domain groups and accounts. For example, in the event of a server failure, you would need to recreate the groups and accounts from scratch on the new server. If you use Active Directory groups and accounts, the groups and accounts will be preserved even if the server hosting Team Foundation Server fails.

In the example deployment, Jill analyzes the business requirements for the new deployment and reviews the security requirements with the project managers. She decides to create three groups to manage the majority of users in the deployment:

• A general group for developers and testers who will participate fully in all projects in the default team project collection. This group will contain the majority of users. She names this group TFS_ProjectContributors, which resolves to the friendly name "Fabrikam Developers and Testers."

• A small group of project administrators who will have permissions to create and manage projects in the collection. She names this group TFS_ProjectAdmins, which resolves to the friendly name "Fabrikam Project Administrators."

• A special, restricted group of contractors who will only have access to one of the projects. She names this group TFS_RestrictedAccess, which resolves to the friendly name "Fabrikam Limited Access."

Later on, as the deployment expands, she might decide to create other groups.

To create a group in Active Directory

• Create a security group that is a local domain, global, or universal group in Active Directory, as best meets your business needs. For example, if the group needs to contain users from more than one domain, the universal group type will best suit your needs. For more information, see Create a New Group (Active Directory Domain Services).

  In the example deployment, Jill creates three Active Directory groups, as specified above.

To create a local group on the server

• Create a local group and give it a name that will quickly identify its purpose. By default, any group you create will have the equivalent permissions of the Users default group on that computer. For more information, see Create a local group.

To create an account to use as a service account in Active Directory

• Create an account in Active Directory, set the password policy according to your business requirements, and make sure that Account is trusted for delegation is selected for the account. For more information, see Create a New User Account (Active Directory Domain Services) and Understanding User Accounts (Active Directory Domain Services).

  In this tutorial, Jill uses the system account Network Service as the service account for Team Foundation Server, but she creates a specific Active Directory account to use as the service account for SharePoint Foundation 2010 and as the data source reader account for SQL Server Reporting Services. She names this account SVCSPTRS.

To create a local account to use as the service account on the server

• Create a local account to use as the service account and then modify its group membership and other properties according to the security requirements for your business. For more information, see Create a local user account.

Home | Prepare for Installation | Install Prerequisites and Team Foundation Server | Configure Team Foundation Server to Support Your Development Teams | Create Back Up Schedule and Plan