Home > Troubleshooting > How to Solve Issues Managing Users on Projects after Upgrade to TFS 2012

How to Solve Issues Managing Users on Projects after Upgrade to TFS 2012

September 12th, 2012 Leave a comment Go to comments

This past weekend we upgraded our server to TFS 2012. After we finished the upgrade, I noticed that I was getting errors while trying to manage permissions on a few of our projects. This is odd because my user account is a TFS Admin, there shouldn’t be anything that I’m not allowed to do and I hadn’t heard of any large security changes that were delivered in 2012.


 

After some investigation I found that the only projects I was having issues managing were the projects that existed since the early days of our server. Our server has existed since 2009 and this makes it’s second major version upgrade of TFS. As with any permissions issue in TFS, you can use TFSSecurity to gather extensive information on the security configuration of almost any object in TFS.

Using that tool, I was able to generate this table:

Project Created in 08 and upgraded to 2010 and now to 2012 (after following the advise of a forum poster about running a TFSSecurity script to add the ManageMembership permissions to this project)
[+] Read [Project ]\Contributors
[+] ManageMembership [Project ]\Contributors
[+] Read [ Project]\Readers
[+] Read [ Project]\Build Services
[+] ManageMembership [Project ]\Build Services
[+] Read [ Project]\Project Administrators
[+] Write [ Project]\Project Administrators
[+] Delete [ Project]\Project Administrators
[+] ManageMembership [Project ]\Project Administrators

Project Created in 2010 and upgraded to 2012

[+] Read [Project]\Builders
[+] Read [Project]\Project Administrators
[+] Write [Project]\Project Administrators
[+] Delete [Project]\Project Administrators
[+] ManageMembership [Project]\Project Administrators
[+] Write [Project]\Build Editors
[+] Delete [Project]\Build Editors
[+] ManageMembership [Project]\Build Editors
[+] Read [Project]\Contributors
[+] Read [Project]\Readers
[+] Read [PC]\Project Collection Valid Users
[+] Read [PC]\Project Collection Service Accounts
[+] Write [PC]\Project Collection Service Accounts
[+] Delete [PC]\Project Collection Service Accounts
[+] ManageMembership [PC]\Project Collection Service Accounts
[+] Read [PC]\Project Collection Administrators
[+] Write [PC]\Project Collection Administrators
[+] Delete [PC]\Project Collection Administrators
[+] ManageMembership [PC]\Project Collection Administrators

Project Created in 2012

[+] Read [Project]\Readers
[+] Read [PC]\Project Collection Build Service Accounts
[+] Read [Project]\Build Administrators
[+] Read [PC]\Project Collection TestService Accounts
[+] Read [Project]\Contributors
[+] Read [Project]\Project Administrators
[+] Write [Project]\Project Administrators
[+] Delete [Project]\Project Administrators
[+] ManageMembership [Project]\Project Administrators
[+] Read [PC]\Project Collection Valid Users
[+] Read [PC]\Project Collection Service Accounts
[+] Write [PC]\Project Collection Service Accounts
[+] Delete [PC]\Project Collection Service Accounts
[+] ManageMembership [PC]\Project Collection Service Accounts
[+] Read [PC]\Project Collection Administrators
[+] Write [PC]\Project Collection Administrators
[+] Delete [PC]\Project Collection Administrators
[+] ManageMembership [PC]\Project Collection Administrators

 

For all intents and purposes the project created in 2010 and 2012 are identical from a permissions standpoint.  The project created in 2008 however was missing the above key ACL entries.  To be honest, I’m not sure if they were there and the upgrade removed them or if something else happened; however, before the upgrade I was able to edit these projects and after I was not.

As I mentioned previously, the TFSSecurity program is very powerful and not only can it give you security information, it can also set it, irrespective of what the UI will allow you to do.  This is how I fixed my issue:

First:  You need to get the GUID of the project that you need to adjust permissions on.  I do not know of a way to get it from 2012.   The easiest way to do this is to get it from VS2010.  When you open team explorer and have the project in question in your list, right click and select properties.  The GUID will be in the field whos value looks like this:

Once you have the GUID of your project, you need to get the SID of your project collection administrators group.

Now that we have both of those pieces of information, we execute the following command

Piecing this command out looks something like this (full documentation found here)

  • /a+ , Add permission (/a just shows permissions)
  • Identity, This means that w’re modifying something in the Identity security namespace
  • vstfs:///Classification/TeamProject/*GUID*, this is the specific object we’re modifying security on. In this case, a project
  • ManageMembership, This is the specific permission in the security namespace that we’re modifying
  • SID, This is the user were performing the security action on
  • ALLOW, We’re allowing them to perform the action
  • /collection, the specific TFS Project Collection that the action will be run against.

Voila, you should now be able to manage groups on the project again.  I ran the same command twice, to see if it would cause an issue and the command exited without doing anything.  Given that test, I believe it’s safe to say that writing a script to run this against every project in your TFS instance, especially if you have a lot of old projects, would be the better idea then doing them all by hand.

If you’re experiencing an issue similar to this, hopefully this solves your problem!

 

P.S. You can see my original forum post here.
(This post updated for more explanation of the command and to fix a display problem with my original example)

Categories: Troubleshooting Tags:
  1. No comments yet.
  1. No trackbacks yet.