[Update 2/1/13] Finally! We now have the updated fix available. We went through quite a bit of testing. It is important to follow the instructions. Please take a moment to read these. I have copied them here from the KB article. If you tweet, blog or share the link for the patch, please use the KB article link. We still need to get the download page updated with the latest info from the KB article.
If you installed the original patch, you can and should install this patch. This one fixes a few additional issues, as detailed in the KB. You do not need to uninstall the original patch – just install this one to update your server.
This patch only contains fixes for the server, so you do not need to install it on your build, version control proxy, or SharePoint computers.
We apologize again for the disruption and appreciate your patience!
Before you install the update:
- Close any instances of Event Viewer that are running (EventVwr.exe).
- Close any instances of Server Manager that are running (ServerManager.exe).
- Close the Team Foundation Administration Console (tfsmgmt.exe).
If you have multiple load-balanced application tiers (ATs):
- Shut down all the ATs except for the one on which you will install the update. Make sure that you close the Admin Console on all these ATs.
- Remove the AT from the load balancer.
- Install the update (as discussed earlier).
- After you install the update to the first AT, install the update on the other ATs one at a time.
- Add the ATs back to the load balancer.
If you are using SQL Mirroring or SQL AlwaysOn features for your databases:
This update requires your SQL Databases to be set to simple recovery mode. To make sure that the update can set simple recovery mode for your databases, do the following before you apply the update:
- If your databases are in a SQL AlwaysOn Availability group, you must remove them from the availability group before you apply the update.
- If the databases are part of a SQL Server database mirroring, you must remove (break) the mirror before you apply the update.
As soon as the update process is complete, you may return the databases to the AlwaysOn group or re-enable database mirroring.
The patch is available here.
[Update 1/14/13] We have found that the patch fails to install correctly for installations where TFS is not installed on the primary drive. I apologize that we didn’t find this, and we all feel really bad about it . As a result, we are pulling the update down while we get this fixed. We will get it updated as soon as we can. If you are blocked by the permissions issue, contact CSS to get the fix until we re-release it. If you already have installed it successfully, you can continue to use it.
[Update 1/11/13] Download the fix . We have now release the patch to fix the problem, including restoring the permissions if you’ve already run into this. Within the hour, the KB article for it will be live.
[Update 1/4/13] We have published the list of bugs that will be fixed in the patch. We plan to have the patch available next week. Also, installing the patch will fix the permissions – it turns out they are not permanently lost. I’ve updated the text below to reflect that.
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 support before 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. Installing the patch will restore 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 <group name> 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.