TFS Build Service Account change causes Build Failures - “Working Folder in use” Failures

We recently had a need to add some additional service accounts to run services as we had a single service account that was getting used in a bit too many places.  During this exercise, we decided to change the service account that our TFS 2010 services were run under and this went off without a hitch.  It is simplified using the Team Foundation Server Administrator Console’s change password feature.

This update password works great for changing service accounts for the TFS 2010 AppTier, Database tier, and SSRS.  What I didn’t realize was it didn’t update (at least with RC1) the build service account.

Updating the Build Service Account or Password

In order to change the build service account in TFS 2010, you can use either the User Interface (TFS Admin Console) or you can use command-line utilities.  For my purposes, being new to TFS, I decided to use the user interface.  The user interface provides the ability to change the password when you stop the build server services, then click Properties.

Under credentials, enter the domain service account and password and click OK.  Then click Start to kick-off get the build services running again.

During our migration process to TFS 2010, we had a requirement to run our build services under a domain account.  This is due to a build that runs an application that updates the status of work items that are present in external bug tracking systems.  Because of this, TFS build services password will be updated as well when using custom accounts such as domain accounts.  This works great which is a great thing! 

Working Folder & Workspace:  Builds are failing!  Help!

The fun part is when you decide to change your Build Services services account – this doesn’t go off without a hitch and recently caused us some grief.  After we updated the user account and password for the build services, we begin to get on all builds (no matter the branch) a failure that reads “The working folder {path} is already in use by the workspace {workspace name} on {build server}.  Arggh!

In order to restore sanity, I had to use a command-line utility to remove the workspaces created and occupied on the build server.  This allowed our builds to start working again and removed the above error.

To correct this problem, first do the following:

1. Connect to the Build Server (unless you have the tools locally)
2. Open a CMD Prompt (elevated)
3. Change to the %programfiles% (or \program files (x86) for 64-bit) \microsoft visual studio 10.0\common7\ide
4. Enter the following command to see workspaces for the old service account:

tf workspaces /collection:https://{tfsapptier}:{port}/tfs/{collectionname} /owner:{machine name}

This will produce a list of workspaces created by the build server to use when creating builds.  I’m unsure, honestly, if this is capped but for whatever reason we began to fail because all the workspaces were assigned to the old service account.  In order to correct this, I had to delete each workspace on the server.

To delete the workspace for a user other than yourself, you must be a Collection Administrator.  To do this, you utilize the tf workspace (notice no “s” like in the other command) -

tf workspace /collection:https://{tfsapptier}:{port}/tfs/{collectionname} /delete {workspaceName}

For workspace name, use the following syntax:   10_1_{serverbuildname};domain\accountname

You should get asked if you would like to do this as the action is permanent and if you trust me then you move forward with a “Y”.

Re-try your build after deleting all the workspaces under the old service account and you should be working again!

Summary

I’m unsure if this is tribal knowledge or not but I thought I would share nonetheless.  It got us this past weekend when I changed our service account password and all of a sudden every build was failing with the error above.  After going through this process, all builds started succeeding and had no errors.

Thanks,

-Chris

Comments

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  June 03, 2010
  Thanks Chris, worked perfectly!

• Anonymous
  June 07, 2010
  Thanks for this - helped out very much.

• Anonymous
  July 21, 2010
  Thank you for this information!!

• Anonymous
  February 05, 2015
  Thanks Chris this helped me to change the build service credentials!