This is the second time we have hit this error so this time it was a quick fix. But if you don’t know what it is you might be led astray by the message. When we have received this error is has nothing to do with permissions. This typically occurs on a build failure:

The real reason is found in the Event Viewer on the TFS Web Server in all these Errors:

If you scroll through the jumbled Web Request Details within the event details you will see:

Exception Message: There is not enough space on the disk.
 (type IOException)
Exception Stack Trace:    at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.WriteCore(Byte[] buffer, Int32 offset, Int32 count)
   at Microsoft.TeamFoundation.Framework.Server.TeamFoundationFileService.InternalCopyTo(Stream source, Stream destination, Int32 bufferSize)
   at Microsoft.TeamFoundation.Framework.Server.TeamFoundationFileService.CopyStreamToTempStream(TeamFoundationRequestContext requestContext, Stream stream, Int64 compressedLength, CompressionType& compressionType, Boolean compressOutput, Boolean useFileStream)
   at Microsoft.TeamFoundation.Framework.Server.TeamFoundationFileService.RetrieveFile(TeamFoundationRequestContext requestContext, Int32 fileId, Boolean compressOutput, Byte[]& hashValue, Int64& contentLength, CompressionType& compressionType, String& fileName, Boolean failOnDeletedFile, Boolean returnNullIfDelta, Boolean forceFileStream, Boolean readIncompleteData)
   at Microsoft.TeamFoundation.Framework.Server.TeamFoundationFileService.RetrieveFile(TeamFoundationRequestContext requestContext, Int32 fileId, Boolean compressOutput, Byte[]& hashValue, Int64& contentLength, CompressionType& compressionType)
   at Microsoft.TeamFoundation.Server.Core.MidTierDownloadState.CacheMiss(FileCacheService fileCacheService, FileInformation fileInfo, Boolean compressOutput)
   at Microsoft.TeamFoundation.Server.Core.FileCacheService.RetrieveFileFromDatabase(TeamFoundationRequestContext requestContext, FileInformation fileInfo, IDownloadState downloadState, Boolean compressOutput, Stream databaseStream)
   at Microsoft.TeamFoundation.Server.Core.GenericDownloadHandler.DownloadFile(TeamFoundationRequestContext requestContext, DownloadContext downloadContext, HttpRequest request, HttpResponse response, HandleErrorDelegate errorDelegate)

The reason we ran out of disk space is due to IIS Logging. We were having giant transaction logs being recorded for all requests to the TFS Web Services. Archiving (deleting ) these restored our space quickly.

Continuing our Quest we currently have the states To Do, In Progress and Done. We need to add another for when it goes into testing so we will call that Boss Battle.

Firstly we need to add the new state to the work item type. Export the Quest work item type:

witadmin exportwitd /collection:http://vsalm:8080/tfs/FabrikamFiberCollection /p:FabrikamFiber /n:Quest /f:%userprofile%\desktop\QuestWitd.xml

Add a new state under witd > WORKITEMTYPE > WORKFLOW > STATES:

<STATE value="Boss Battle"/>

Modify the transitions to go through the new state:

<TRANSITION from="In Progress" to="Done">
<TRANSITION from="In Progress" to="Boss Battle">

<TRANSITION from="Done" to="In Progress">
<TRANSITION from="Done" to="Boss Battle">

In practice you might want to add more transitions around the state. This is much easier using the TFS Power Tools Process Template Editor. This will now have the workflow in place with the new state, but when that state is selected the work item will not appear on the board.

Export the process configuration definition:

witadmin exportprocessconfig /collection:http://vsalm:8080/tfs/FabrikamFiberCollection /p:FabrikamFiber /f:%userprofile%\desktop\ProcessConfiguration.xml

Under the TaskBacklog add a new InProgress state:

<States>
  <State type="Proposed" value="To Do" />
  <State type="InProgress" value="In Progress" />
  <State type="InProgress" value="Boss Battle" />
  <State type="Complete" value="Done" />
</States>

Import the process configuration definition:

witadmin importprocessconfig /collection:http://vsalm:8080/tfs/FabrikamFiberCollection /p:FabrikamFiber /f:%userprofile%\desktop\ProcessConfiguration.xml

You now have a new column on your iteration board:

We have come from originally a TFS 2008 CMMI Work Item Template and have upgrade through 2010 and 2012. When we upgraded to TFS 2013 we were keen to use the Agile Portfolio Management features. After enabling it we ended up with the categories Features and Requirements. These categories names we find are often use interchangeably so having them mean distinctly different  things was confusing.

By default if you are the Scrum template you get something far less confusing, Features and Backlog items. Initiatives can be added following Agile Portfolio Management: Using TFS to support backlogs across multiple teams guide.

So when it came to use agile portfolio management the hierarchy is was not clear. Fortunately this is easily fixed. I assume the TFS Team did not what to end up with another area like Team Projects that is not able to be renamed. To begin open the Developer Command Prompt which has the paths configured for witadmin.

The examples I have done below have been done on the Visual Studio 2013 ALM Virtual Machine provided by Brian Keller. I recommend anyone who is a TFS Admin have the appropriate Visual Studio ALM Virtual Machines for testing changes on. Especially if you are managing a small team since you are unlikely to have a staging environment and setting one up is too much work. Consider these staging and test environments. With the error I got below no one was effected while I worked out the solution.

Renaming Categories

1. Export the process configuration definition to an xml file: 
   

   witadmin exportprocessconfig /collection:http://vsalm:8080/tfs/FabrikamFiberCollection /p:FabrikamFiber /f:%userprofile%\desktop\ProcessConfiguration.xml 

2. Modify the export xml setting the name to something more appropriate:
   

   <!-- Feature to Saga -->
   <PortfolioBacklog category="Microsoft.FeatureCategory" pluralName="Features" singularName="Feature">
   <PortfolioBacklog category="Microsoft.FeatureCategory" pluralName="Sagas" singularName="Saga">
   
   <!-- Backlog Item to Journey -->
   <RequirementBacklog category="Microsoft.RequirementCategory" parent="Microsoft.FeatureCategory" pluralName="Backlog items" singularName="Product Backlog Item">
   <RequirementBacklog category="Microsoft.RequirementCategory" parent="Microsoft.FeatureCategory" pluralName="Journeys" singularName="Journey">
   
   <!-- Task to Quest -->
   <TaskBacklog category="Microsoft.TaskCategory" parent="Microsoft.RequirementCategory" pluralName="Tasks" singularName="Task">
   <TaskBacklog category="Microsoft.TaskCategory" parent="Microsoft.RequirementCategory" pluralName="Quests" singularName="Quest">

3. Import the process configuration definition file: 

   witadmin importprocessconfig /collection:http://vsalm:8080/tfs/FabrikamFiberCollection /p:FabrikamFiber /f:%userprofile%\desktop\ProcessConfiguration.xml 

Refreshing the browser after renaming the categories, my URL is wrong since the category no longer exists but I get this very good message:

After messing with the process configuration and then getting an error message containing the line, “Don’t worry, the system is not broken”, is very comforting.

Renaming Work Item Types

This is appears easy with just one command.

Rename Feature to Saga:

witadmin renamewitd /collection:http://vsalm:8080/tfs/FabrikamFiberCollection /p:FabrikamFiber /n:Feature /new:Saga

A confirmation prompt appears:

Are you sure you want to rename the work item type Task to the new name of Quest? (Yes/No)

Rename Task to Quest:

witadmin renamewitd /collection:http://vsalm:8080/tfs/FabrikamFiberCollection /p:FabrikamFiber /n:Task /new:Quest

However after doing this you may get this nasty error message when viewing the backlog essentially telling you this time your system is broken and not really useful information on how to fix it:

If you export and then import the process configuration definition it will tell you a reason why this could be.

Correcting this color reference in the xml as such however gives you this error.

<!-- Update Task to Quest for the new work item type name -->
<WorkItemColor primary="FFF2CB1D" secondary="FFF6F5D2" name="Task" />
<WorkItemColor primary="FFF2CB1D" secondary="FFF6F5D2" name="Quest" />

Regardless neither of them are the error. This issue is an application pool recycle of TFS is required. After the application pool recycle, the backlog will be working again.

Now you can upload your modified process configuration definition correcting the work item colors.

Result

Now I have a much more interesting hierarchy: