Some customers have sent us questions like "I can create a team project, but when I try to check-in a file to that project, I get a permission denied error.  Why is that?"

Specifically you might see a message like:

TF14098: Access denied: User <you> needs AdminProjectRights permission(s) for <project>.

or

 TF14098: Access Denied: User <you> needs Checkin permission (s) for $/<projectname>/<folder>/<filename>

Unfortunately, as of September 2015, the web experience in visualstudio.com does not allow you to self-diagnose why you don't have the permissions you think you should have.  So to do this, you'll need the help of a Project Administrator.

Below is a walk through of how a project administrator can figure out why a team member does not have Check-in permissions for their team project.  This post applies for both TFVC and Git, although the screenshots below show TFVC.

As a project administrator, navigate to your project's Version Control security page.  To do that, navigate to your Visual Studio Online project like this:

ie: https://<youraccount>.visualstudio.com/DefaultCollection/<project>

Click the gear icon in the top right corner to get to the administration site, and from there click the Version Control tab.  You'll see something like this:

The problem with this page is it only tells you the default permissions for the various user groups for this project.  For example you can see what permissions you get by being a member of the Build Administrators group or the Readers group.  However these are just the default values and it does not mean that every member of that group has those permissions.  If you are a member of multiple groups, and one group grants you permission, but another group denies you that permission, then your overall permission will be Denied.  Since project administrators can add you to multiple groups and customize each group, they can quickly create quite a mess regarding individual permissions.

What we want, which is missing from Visual Studio Online today, is a way to see what the overall permissions for an individual user are.  Here's how to do that.

Click the Add... button and select Add User.  That will pop-up a window like below.  Enter the name of the user in question to add the user to the team project directly, and click Save Changes.

Now the user will show up individually under the Users section as shown below.  Select that user in the center column.  When you do that, the permissions on the right will be the specific permissions for that user.  That's what we need to see! From there you can see in this example that the Check-in permission is set to Inherited Deny.   Hover your mouse over the Deny setting and you'll see a Why? link appear. 

Click on Why? to see the root cause of the Deny.  In this contrived example I see this:

This tells me that the Deny permission was inherited from the Readers group.  So the fix in this case would be to either remove the Deny permission from the Readers group, or remove this user from the Readers group.  Either solution will work and the end result is the user will inherit the Allowed permission by virtue of belonging to the Contributors group.  In this contrived example, the right fix is to remove the Deny permission from the Readers group; set it back to Not Set.

 I hope that helps!

P.S.  I saw another interesting case of this that was caused by the user referencing the wrong project.  This was further complicated by the recent Rename Project feature.  The customer had two projects with similar names, only different by a space.  They had a project named 'FooBar' and wanted to deprecate it.  So they renamed it to 'FooBar - Old' and explicitly denied check-in permissions for all users.  Then they created a new project named 'Foo Bar' (with a space).   The fact the new project name had a space was evidently accidental and not well communicated.  So users continued to use their existing workspaces that referenced 'FooBar.'  That project name technically didn't exist anymore, but we in Visual Studio Online made a big effort to support backward compatibility.  So users with old workspaces that referenced 'FooBar' were internally redirected to the new name of the old project 'FooBar - Old' and these users were getting the permission denied error.  The fix was to update their workspace to refer to the new project 'Foo Bar' (with a space) or rename the new project to be the name of the old project (without a space), reusing the 'FooBar' name.

So check the project name carefully!

If you try to use SQL 2008 R2 RTM you will hit this error:

[Error] TF400744: An error occurred while executing the following script: WorkItemTrackingToDev11M55.sql. Failed batch starts on the line 9. Statement line: 42. Script line: 50. Error: 102 Incorrect syntax near '('.

After upgrading your SQL Server to 2008 R2 SP1 or newer, you can restart your TFS upgrade by opening the TFS Administration Console.  Navigate to the Team Project Collections node.  Select each collection, go to the Status tab at the bottom of the page, and select the failed job.  A Retry Job link will appear on the right.  Click that to restart the job.  Repeat for all failed collections.

 You can download SQL 2008 R2 SP1 here: https://www.microsoft.com/en-us/download/details.aspx?id=26727

[8/26/2013 1:04:31
PM] [Info] Marking TFS databases

[8/26/2013 1:04:31
PM] [Info] Executing on Tfs_Warehouse: EXEC prc_SetTransactionMark TfsMarkTfpt

[8/26/2013 1:04:31
PM] [Error]

Exception Message:
TF30040: The database is not correctly configured. Contact your Team Foundation
Server administrator. (type DatabaseConfigurationException)

.... 

Exception Message:
Could not find stored procedure 'prc_SetTransactionMark'. (type SqlException)

[Info   @13:04:44.102] Node returned: Error

[Error  @13:04:44.102] [8/26/2013 1:04:11 PM] [Info]
Requested Backup Job: Full

This bug has been fixed in TFS 2013 RTM.  For RC users you can fix it now by running this SQL script against your Tfs_Warehouse database. 

USE [Tfs_Warehouse]

IF
OBJECT_ID('dbo.prc_SetTransactionMark', 'P') IS NOT NULL DROP PROCEDURE
dbo.prc_SetTransactionMark;

GO

IF
OBJECT_ID('dbo.tbl_TransactionMark', 'U') IS NULL

CREATE TABLE
tbl_TransactionMark (

    LogMark TINYINT CONSTRAINT
PK_tbl_TransactionMark PRIMARY KEY CLUSTERED

)

GO

CREATE PROCEDURE
prc_SetTransactionMark

    @name      
NVARCHAR (128)

AS

SET NOCOUNT ON

BEGIN TRANSACTION
@name WITH MARK

DELETE FROM
tbl_TransactionMark WHERE LogMark = 1

INSERT INTO
tbl_TransactionMark (LogMark) VALUES (1)

COMMIT TRANSACTION

GO

Permissions at the server scope can only be granted when the current database is master

This is a bug in the Scheduled Backups wizard in TFS 2012 (QU2 and QU3).   The workaround is to set the default database for the running user's SQL Login to be 'master'.

I'll get this fixed in the next version, but in the meantime you can workaround this issue by setting the default database back to 'master' by running this SQL query on the server(s) hosting the TFS databases.  Make sure to change the domain\username value to the account that is running the wizard.

USE [master]
ALTER LOGIN [domain\username]
WITH DEFAULT_DATABASE = [master]

The system cannot find the file specified. (2147942402, 80070002)

IISRESET failing is not a problem for TFS, but nevertheless you may want to address this.  To fix it, open Add / Remove Programs (appwiz.cpl) and run Repair on the .NET 4.0 Client component.  This requires a reboot.

TF246062: Two or more databases are in conflict because they are each designated as the owners of the following schema: Framework. The schema is for the host with the following name and ID: CollectionName, 4bace481-2439-49c8-b017-77ee3da4ce29. The databases with this conflict are: Data Source=SQLInstance1;Initial Catalog=Tfs_CollectionName;Integrated Security=True, Data Source=SQLInstance2;Initial Catalog=Tfs_CollectionName;Integrated Security=True. You must specify one and only one database owner for the schema in the searchable SQL Server instances for this deployment of Team Foundation Server.

TF246064: No database could be found for the following host: MyCollection. The host has the following ID: 4bace481-2439-49c8-b017-77ee3da4ce29. To fix this problem, use the TFSConfig RemapDBs command-line tool and make sure that you specify the SQL Server instance that contains this database.. 

Some examples scenarios that would cause this issue:

1. You used the FQDN of your SQL instance when installing Beta2, but in the RTM upgrade wizard you used the simple machine name.  In this case another easy workaround is to use the FQDN again in the upgrade wizard.

2. You used the machine name of the local machine when installing Beta2, and later created a new team project collection using the SQL identifier "localhost"

The workaround to both errors is to run 'RemapDbs' to use a consistent naming convention for your SQL databases.

C:\program files\Microsoft Team Foundation Server 2010\tools\tfsconfig remapdbs /sqlinstances:MyServer,MyOtherServer /databaseName:MyServer;Tfs_Configuration /AnalysisInstance:AnalysisServerName

TFS 2010 provides a lot of flexibility in how you manage your collections.  You can have multiple collections and easily move them from one SQL instance to another.  One common scenario is to load balance your system by spreading your collections across multiple data tiers.  You can do this before, during, or after upgrade to RTM.  If you move a collection as part of your upgrade, you must run the RemapDBs command before the upgrade.  The steps to follow are:

1. Backup DBs.

2. Uninstall TFS Beta 2 / Install TFS RTM

3. Move your collection database (backup/restore from SQL) to the new data tier

4. On TFS Application tier, run 'tfsconfig.exe remapdbs' and specify all your data tiers.  For example: 

tfsconfig remapdbs /sqlinstances:server1,server2\instancename /databasename:datatier1;Tfs_Configuration /analysisinstance:server3

5. Run the TFS Upgrade Wizard.

Note that if you move all your TFS databases to a new single data tier, you don't need to run RemapDBs.  TFS is smart enough to figure it out.  If you move one or a few database, you must run it.  Just to be safe I recommend you run RemapDBs anytime you move a TFS database.  There's no harm in running it.