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