Invalidate cache of TFS after a Server Move

If you move your TFS server in a new hardware be sure to follow the instructions in MSDN: Move or clone Team Foundation Server (hardware move).

There are many reason why you want to move TFS to a different hardware, probably you want to use a new powerful hardware and you have not virtualized TFS, or you need to upgrade TFS and you need to move Sql to a new hardware with a more recent version of SQL. Sometimes you simply want to startup with a clean TFS machine (probably you installed too much stuff in the old one, or you have some other services running in the very same machine).

One of the important step is refreshing the data cache on client computers, sometimes if you forget to follow this step client start behaving weird. An example could be: a user is reporting that Visual Studio shows some files as “pending add” but the file was already in TFVC and also the user is able to see the file from the web interface of TFS. The problem is that Visual Studio erroneusly believe that a file needs to be added to source code repository but the file is already there.

To globally invalidate all caches for all users you can use the witadmin rebuildcache command (as described in previous listed MSDN article). With this command you are sure that, upon new connection, all clients will have cache invalidated.

Also follow this instruction to refresh the Version Control Cache on client computers to ensure that all workspaces are in sync with the new server.

Always remember, after moving TFS to a new hardware it is a good idea to invalidate cache from server and to tell all users to refresh local version control cache to avoid weird problems.

Gian Maria.

User added to Team Project have no permission after upgrade from TFS2010 to TFS2013

I’ve performed an upgrade from TFS2010 to TFS2013 at a customer site last week. The upgrade consisted in moving to a different machine and from a Workstation to an Active Directory Domain. The operation was simple, because the customer uses only Source Control and they want to spent minimal time in the operation, so we decided for this strategy

  1. Stop TFS in the old machine
  2. Backup and restore db in the new machine
  3. Upgrade and verify that everything works correctly

They do not care about user remapping, or reporting services or other stuff, they just want to do a quick  migration to new version to use local workspaces new feature (introduced with TFS 2012). The do not care to remap old user to new user, they only care not to spend too much time in the upgrade.

The upgrade went smoothly, but we start facing a couple of problem. The first one is: after the migration, each team project has no user, because the machine is now joined to a domain with different users, but if we add users to a team project, they are not able to connect to team project, and they seems to have no permission. All the users that are Project collection Administrators can use TFS with no problem.

The reason is simple, in TFS2012 the concept of Teams was introduced in the product. Each Team Project can have multiple Teams and when you add users from the home page of the Team, you are actually adding people to a TFS Group that correspond to that Team. For each Team Project a default Team with the same name of the Team Project is automatically created.

image

Figure 1: Users added to Team through home page.

In the above picture, I’ve added two user to the BuildExperiments Team, we can verify this in the Settings page of the Team Project.

image

Figure 2: User added through the home page, are added to the corresponding Tfs Security Group

To understand the permission of that users, you should use the administration section of TFS, as you can see from Figure 3, BuildExperiments team has no permission associated.

image

Figure 3: Permission associated to the Team Group

The reason for this is: the Team is not part of the Contributors TFS Group, it can be verified from the Member Of part of group properties

image

Figure 4: Team group belongs only to the Project Valid User

When you create a new Team Project, the default team (with the same name of the Team Project) is automatically added to the Contributors group, it is that team that gives user the right to access the Team Project. To fix the above problem you can manually add the Team Tfs Group to the Contributors group using the Join Group button. Once the Team group is added to the Contributors group, all the people you add with web interface are now able to access the Team Project.

This behavior is the standard in TFS, if you create a new Team, the Ui suggests you to choose to add the new Team Group to an existing group to inherit permission.

image

Team 5: Default option for a new group is to be part of the Contributors group.

This is an optional choice, you can choose a different security group or you can choose no group, but you should then remember to explicitly add permission to the corresponding Team Group.

When people does not access TFS and you believe that they should, always double check all the groups they belong and the effective permissions associated to them.

Gian Maria.

TFSRestore.exe, database restored with strange suffix

This problem happens if you mix Team Foundation Server backup tools, the symptom is: you launch TfsRestore.exe and point to a local folder where a TFS backup is located, and when the database are restored they have strange suffix.

image

Figure 1: Strange suffix in database names after a restore with TfsRestore.exe

This happens when you use TfsRestore.exe to restore a backup taken with the Tfs Backup Scheduled Backup. Basically you have two distinct way to backup your TFS: the first one is using the TfsBackup.exe and TfsRestore.exe utilities as described in “Backup and Restore data for TFS”, the other one is the scheduled backup, originally included in TFS 2010 and TFS 2012 power tools, and now part of the base product starting from TFS 2012 Update 2.

You should clearly use the correct restore tool based from the origin of the backup set; this specific problem (strange suffix of names) originates by the TfsRestore.exe utility assuming that the backup set is taken from TfsBackup.exe, that creates file names based on Database Names. The scheduled backup utility create backup-sets adding suffix to file names, because the real file names are written in the backup summary (an xml file).

But how can you understand what was the tool that generates the backup if someone told you something like: in share \\backupXX\TFS\ you will find TFS Backup and you should use them to test an upgrade to new version? The answer is really simple, backup produced by the TfsBackup.exe tool are simple Sql Server backup, so you will find a bak file for each database.

image

Figure 2: Typical Tfs backup output of TfsBackup.exe

A really different output is produced by Scheduled Backup.

image

Figure 3: Backup folder of Scheduled Backups

First of all all file have a suffix that identify the backup set, then you have the Xml File called BackupSets that identify the various Backup Sets. This kind of backup should be restored only with the Scheduled Backup Restore option, present in the Administration Console.

image

Figure 4: Restore database procedure to restore backups taken from a Scheduled Backup procedure

Gian Maria

Upgrade TFS2010 to TFS11 with Detach and Attach

One of the simplest way to upgrade with minimum risk a Project Collection from TFS 2010 to TFS11 Beta is using the detach/attach feature of TFS, introduced with version 2010.  Basically all you need to do is Detach the project collection from the old TFS 2010 server and reattach to a brand new TFS11 server, you can read about the whole procedure in an old post that explain how to Move a Team Project Collection from one server to another one.

This operation works because the attach routine of TFS11 performs an upgrade during the attach phase and this is done transparently to the user. The real good aspect of this operation is that after the attach process you can reattach the Project Collection in the old server and continue to work wit it. The attach procedure in TFS11 is really simple, when you restored the Project Collection Database in the new server, you should open TFS Administration Console and choose to Attach a Project Collection.

List of available Project Collection to Attach

Figure 1: Attach wizard automatically detect any database that contains a detached Project Collection.

You should only give a name to the project collection do verification checks and press Attach, everything is done automatically.

Result of Attach Operation

Figure 2: Result of Attach operation, the Project Collection is now converted to TFS11.

This technique is optimal to evaluate the upgrade process, without requiring any discontinuity in the service, all you need to do is detach/attach the Team Project Collection from the old server to the new one, then perform all the manual upgrade operations needed to use new features and perform some test to verify if the upgrade procedure did not ruin anything. All these operation can be performed while the team still work on the old TFS server because you can immediately reattach the Project Collection in the old server. When everything is ok you can schedule an offline period where you will do another detach/attach/upgrade to move all the team on upgraded collection.

After the collection is imported you still need to do some manual post upgrade operations if you want to use the new features offered by TFS11, because the imported collection still contains old Process Template Definitions, that does not support new features. To accomplish this operation you need to download Visual Studio 11 Beta Update Files, a tool to enable new TFS11 features after a Collection was upgraded from TFS2010. You can find a detailed discussion in this MSDN article named: Updating an Upgraded Team Project to Access New Features.

If you omit this part you got errors when you try to use new features related to Work Items, if you browse the home page of the project with TFS Web Access you will got an error

Errors in Web Access home page because the Process Template was not upgraded

Figure 3: Imported Team Project still uses old Process Template, new Web Access features are not available.

After you unzip the Visual Studio 11 Beta Update Files and issued the upgrade command Es. updateProject "http://vsalm:8080/tfs/ImportedCollection" "Tailspin Toys" Agile you can use all the new cool feature of TFS11.

image

Figure 4: Now everything works, you can see the burndown and tiles for favorites elements

Now your Project Collection is ready to work with TFS11.

Gian Maria.