When I first set this up, I had to ask around our developers for a volunteer to be our ‘build service account’ user, but as this person is part of the project we are working on, this wasn’t very ideal. Each morning I would find alert emails notifying me that this developer had changed all my work items and had completed a build (very hard to go through when auditing the build history, identifying which were automated and which were real work item changes).

In the end, I decided to look around to find a solution to using a Licensed User as the build account and use some other account. It didn’t matter which account would be used, but as long as it wasn’t one of the developers, I’d be happy.

I found an article on the MSDN Team Foundation Server – Build Automation forums:

If you configure it to use the TFS service account (just like the application pool hosting the application tier’s web services) you should be able to work-around this problem.

I tried this, and was repeatedly faced with the following error when attempting to start the service:

TF224004: The Visual Studio Team Foundation Build service failed to start because <domain>\TFSSERVICE does not have the required access permissions for address http://<server>:9191/Build/v2.0/AgentService.asmx.

At first I thought this was a problem with SharePoint as the post suggested, but I couldn’t find anywhere to solve it.

To cut to the chase, I solved the problem by setting the service to run as the Local System account. I had to add this account to the [SERVER]\Service Accounts group on TFS using TFSSecurity.exe. This can be done by spinning up an instance of Visual Studio Command Prompt on a machine that has Team Explorer installed, and entering the following command (this was used from a guide here):

tfssecurity.exe /server:<server> /g+ “[SERVER]\Service Accounts” “NT AUTHORITY\SYSTEM”

After this was done, I checked in the TFS Group Membership dialogue under the [SERVER]Service Accounts group and confirmed that the service account had been added:

NT AUTHORITYSYSTEM in the TFS Service Accounts group

When attempting to spawn a build using this newly set up account, they seemed to fail because of access permissions to the drop folder. Indeed, the system account should already have access to the drop folder, and I verified this many times. However, I hadn’t considered that the account wasn’t on the sharing security list, as it was accessing the folder by network name “\\<server>\Builds” which had only read access for “Everyone”. I added the “SYSTEM” account to the list as read and change permissions:

SYSTEM on Drop folder permissions

Success! The builds now run perfectly fine and I am now able to clarify the history of my builds and work items!

TfsDeleteProject /server:tfs-server-name "Project Name" /force

This appeared to work except for the exception we got from SharePoint Services:

Exception of type 'Microsoft.SharePoint.SoapServer.SoapServerException' was thrown.

Fair enough, it seemed we had a problem that the team portal had broken somehow, but this was preventing us from re-creating the team project once more because the wizard was unable to create the site over the top of this one.

Unfortunately when attempting to browse to the site, we got a “400 Bad Request” error, and when attempting to delete the site using the Central Administration, we couldn’t select it from the list. The site truly seemed to be a ghost (or relic) of what was once a great site.

Fortunately, after my colleague found this article explaining how to delete orphaned sites from WSS, we were able to solve the whole problem using step 2: removing the WSS_Content database from WSS, and re-adding it.

This idiotic process of deleting a team project certainly needs cleaning up in the next version, but for now, I hope this helps anyone else with this problem.