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.

image 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!

image 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:http://{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:http://{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!


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.



Digg This
Comments (5)

  1. ChrAd says:

    Hey all-

    I received the following question from a reader –


    Hi, also have the same problem with the Team Build after changing the build service account. Post:…/tfs-build-service-account-change-causes-build-failures-working-folder-in-use-failures.aspx My problem, i have a main TFS server and a build server. on which must i call the TF.exe utility`? I could not find the tf.exe Tool on booth machines, i also have TFS 2010 installed (x64). Where can i get this tool or in which path can i find it?


    The tf.exe utility is installed as a x86 bit utility which means you have to use the directory %programfiles% (x86) to use the utility.  This tool should be available on any machine that has TFS 2010 Team Explorer installed.  To simplify things, I usually just add tf.exe to my path so I can easily drop to a command-line and utilize it.  The full path on a x64 with Team Explorer installed should be – program files (x86)microsoft visual studio 10.0common7idetf.exe – and this should get ya rockin & rollin.

    I'm also not sure if you are thinking you have to issue this command from the actual build server.  This is not the case at all.  You can issue this from any server (even your workstation like I do) as you are using the same path via /collection.

    Hope this helps,


  2. Chooksii says:

    Thanks Chris, worked perfectly!

  3. Greg Lambert says:

    Thanks for this – helped out very much.

  4. Hir says:

    Thank you for this information!!

  5. Fernando Auresco says:

    Thanks Chris this helped me to change the build service credentials!

Skip to main content