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.

Troubleshoot Error TF14044 in build vNext for TFS2015

I upgraded a TFS2012 to TFS2015 Update 1 at a customer site and one of the reason why the customer want to upgrade is the new build system introduced in TFS 2015. Sadly enough, after the upgrade we created a simple build but it failed returning a permission error.

TF14044: Access Denied: User Project Collection Build Service (TEAM FOUNDATION) needs the CreateWorkspace global permission(s).

We were really puzzled, because the user used to run the build (TFSBuild) was correctly set into the Project Collection Build Service account, and that group has all the permissions to create a workspace. We double check permissions for TFSBuild and Project Collection Build Service account and everything is ok, still the error was there.

Error of the build

Figure 1: Error raised for any build created with the new build system

After spending some time double checking all permissions for the various groups without any success I realized that I did not read with attention error message TFS was giving to me. The error is telling me: User Project Collection Build Service needs the CreateWorkspace and the key is on the word User.

To solve this problem simply open the security page of the Project Collection and select the Users tab. In this screen you should be able to see all the users that belongs to the collection and you should find a couple of special users called Project Build Service (TEAM FOUNDATION) and Project Collection Build Service (TEAM FOUNDATION).

The two users related to the new Build System

Figure 2: The two users related to new Build System

It turned out that those two users really did not have correct permission to create a workspace (due to some security restriction) and they does not belong to the Project Collection Build Service TFS Group. To solve this problem simply add those two users (Project Build Service (TEAM FOUNDATION) and Project Collection Build Service (TEAM FOUNDATION)) to the Project Collection Build Service Group, so they will have all needed permission to issue a build.

If you are curious why are there two special Users to run the build, the reason is the ability on the new build system to choose the level of authorization you need on the general tab.

Build Job authorization scope for new build system.

Figure 3: Build Job authorization scope for new build system.

Choosing Project Collection scope is needed if the build needs to access data from multiple Team Projects, if the build operates in a single Team Project you can safely use the Current Project setting.

Gian Maria

Use DNS for your TFS installation

When installing TFS one of the most important and often most forgotten step is using DNS to give TFS Friendly names. The procedure is described in this old post by Ed Blankenship and details all the operations you need to do to use friendly DNS entries for all of machines included in a standard TFS Installation.

Using a DNS friendly name bring a lot of advantages, but essentially it is necessary to mitigate the work needed if you need to migrate TFS to a new hardware / machine.

Instead of accessing your favorite TFS instance with http://machinename:8080/tfs/projectcollection you simply create an alias in your DNS to access TFS to http://tfs.yourcompany.local:8080/tfs/defaultcollection. With such a simple change you can move TFS to a new machine and the client will not notice anything (at most they will need to refresh cache).

image

Figure 1: DNS alias for the Application Tier in action

It is also advisable to use DNS even for the Data Tier and even if the Data Tier is installed in the same machine of the Application Tier (Single server installation). This will mitigate the work needed if you decide in the future to move Data Tier to a different machine. In a simple installation I have on my test domain I have those alias defined for my Main TFS Instance.

tfs.cyberpunk.local: the machine where TFS is installed
data.tfs.cyberpunk.local: the machine where the Sql Server used by TFS is installed
warehouse.tfs.cyberpunk.local: the machine with the Sql Server Analysis Service
reports.tfs.cyberpunk.local: the machine with Sql Server Reporting services installed

Thanks to these aliases I configured my  Data Tier using DNS friendly names.

image

Figure 2: Configuration for Data Tier is also done with friendly DNS names

Even for the Reporting configuration I decided to use DNS aliases.

image

Figure 3: Reporting configuration in TFS also uses friendly DNS names

Using friendly DNS name will greatly simplify changing topology of your TFS installation in the future

In my scenario all those 4 DNS entries are simple ALIAS to the very same machine, but if I will decide to split to a Two Machine installation or I decided to move to different hardware / Virtual machine, all the users and all the configurations will remain the very same, because I can simply change the DNS ALIAS to point to the new server.

There are also other part of TFS that will benefict of friendly names, one of the most notably examples is the Drop Folder for your build. Instead of using the name of the machine or the NAS as drop location (something like \\nas2\tfs\drops) use a name like \\drops.tfs.cyberpunk.local\\drops\\etcetc. Sometimes, years after years, builds number will increase and you need to move drop folder on a bigger network share or into a different NAS. If you do not have friendly names, all of your old builds result will point to the old incorrect location and this is super-annoying.

The very same rules apply to symbol share and in general to any address you use in any TFS configuration (build, release, etc). Once you setup a friendly name with DNS you are not bound to the physical name of the machine and you will have a easier time changing TFS topology in the future.

If you still have your TFS not configured with DNS Friendly names, please fix the situation as soon as possible, because it will be a great gain in the future.

Gian Maria.

Create a safe clone of your TFS environment

ChangeServerId to avoid confusion of client tools

Around the web there are a lot of resources about how to create a clone of your TFS environment for testing purpose. The most important step was always running the TfsCongfig ChangeServerId Command as described in the Move Team Foundation Server from your hardware configuration to another.

With the new wave of guidance for TFS 2015, a new interesting article cames out on how to do a Dry Run in a pre-production environment. In that articles a couple of tricks worth a mention, because they are really interesting and easy to do.

Risk of corrupting production environment

Tfs uses a lot of extra tools and products to fulfill it functions, it is based on Sql Server database but it communicates also with Reporting Services, Sharepoint, SCVMM for Lab management, test controllers and so on. When you restore a backup of your production environment to a clone (pre-production) environment, you need to be sure that this cloned installation does not corrupt your production environment.

As an example, if cloned server still uses the same Reporting Services instance of production server, you will probably end with a corrupted Reporting Services Database.

Protect your environment

In the above article, a couple of simple technique are described to avoid your cloned pre-production TFS corrupt something in production environment.

Edit your hosts file to make all of production servers not reachable from cloned server.

This is the simplest but most efficient trick, if you modifiy hosts file in cloned machine, giving an inexistent ip address for all the names of machines related to TFS environment, you are pretty sure that cloned environment cannot corrupt other services.

If for some reason you forgot to change Lab Management SCVMM Address or Sharepoint, cloned machine is not able to reach them, because name resolves to invalid address.

Use a different user to run TFS Service cloned environment, and be sure that this user has no special permission

Usually TFS Services runs with an account called TFService, and this account has lot of privileges in all machines related to TFS environment. As an example, it has right to manage SCVMM in a Lab Management scenario. If you create a user called TFSClonedService or TFSServiceCloned, withouth no special permission, and use that user to run cloned TFS environment, you are pretty sure that if cloned environment try to contact some external service (Ex SCVMM, Report Service, Etc) you will get a Unauthorized exception.

Remember that running a cloned TFS instance is an operation that should be done with great care, and you should adopt all techniques useful to limit accidental damage to production environment.

Gian Maria.

Work Item query by category

This is a really old functionality of TFS, but it turns out that sometimes some people missed it. When you create a query, you can add a condition on Work Item Type.

This image shows combo box rendered by the ui when you are using the equal operator

Figure 1: Add condition to Work Item Type

As you can see, you can require the Work Item Type to be equal to specific value, and the UI renders a nice combo box with all permitted values to help the user choose right value.

You can also use the in operator, to specify a comma separated list of allowed types.

In operator in Work Item Query allow to specify a comma separated query of values

Figure 2: The in operator in Work Item Query

Finally TFS has a nice concepts called Work Item Category to group togheter all Work Item Types that shared some common behavior. As an example, all types that represents a concept of requirement are shown on the Backload Board, while Work Items that represents a Task are represented in the Task Board. If you choose the in operator to specify a condition on Work Item Type, you can choose from Work Item Categories.

If you choose In Group operator you can choose between Work Item Categories instead of types

Figure 3: Query with the “in group” operator  allows you yo choose between Work Item Categories

There are many use case for this functionality, Microsoft Test Manager used Requirement category to create a generic query that lists “requirements” and is valid for all template. You can use this feature if you need to create query that spans multiple project with different project template.

image

Figure 4: Query for requirements on multiple Team Project

In Figure 4 I represented a simple query to list all requirements associated to me for every Team Project. As you can see from the result, I got Work Item Type “Requirement” from a CMMI Project and “Product Backlog Item” from a Scrum project.

Gian Maria.