TFS 2012 Update 1: Permissions lost on attaching a collection (fix available in early January)

We want to let you know that we’ve discovered an issue where permissions are lost on attaching a collection to a server that is running TFS 2012 Update 1 or executing tfsconfig changeServerId (that command is used after cloning an existing server or cloning a collection). If you are not using the feature of detaching and attaching collections to move or clone them, you can ignore the rest of this post.

We are in the process of creating a patch to fix this issue, and it will be available in early January (we’ll post an update when it is available). The issue stems from an infrastructural change that we made for the Team Foundation Service but only affects on-premises installations.

Until the patch is available, we recommend that you do not attach a collection to a server running TFS 2012 Update 1 or that you contact customer supportbefore attaching a collection in order for them to help you install a temporary fix.

There are two issues around the handling of permissions in the collection attachment process. The first issue results in a set of permissions being lost. These are the permissions that indicate which groups and users have access to a collection. These permissions are lost and must be recreated by an admin. In the case where the collection has been detached from a pre-Update 1 server, attaching a backup of the collection to the original server will be the easiest way to see what those permissions were and re-create them. If the collection was detached from an Update 1 server, customer support will be able to help you install a fix prior to attaching the collection. If there is no backup, you will need to re-create the permissions.

The second issue results in a set of permissions not getting imported into the configuration database from the collection database – they are just left in the collection database. Since they are still there, a SQL script can be used to import them.

As a result of the issue, you may see one or more of the following.

• Contributors are unable to see team projects in the collection from any client (Visual Studio, web access, Team Explorer Everywhere, etc.).
  
• Permissions no longer work on collection level groups when the server ID was changed, a collection was migrated from another server, or the same collection was attached multiple times (such as when cloning).
• Navigating to the team project directly and then going to the admin page results in a “TF400898: An Internal Error Occurred” being displayed for a user who is a member of the Team Project Administrators group.
• TF50632: An error occurred removing the group member. There is no group member with the security identifier (SID)
  
• There are no build process templates in the build definition editor drop down.
  
• TF214008: No build definition was found with the URI vstfs:///Build/Definition/4. Either the URI does not exist or does not have permission to access it.
• In the Team Explorer Builds page, “No builds exist for this definition” for a definition where there are builds.
  

If you have been affected by this issue, please contact customer support. They will be able to help you determine the quickest way to recover from the situation.

I apologize for the inconvenience.