Permissions required for Team Build Retention Policy in TFS2008

Grant Holliday’s blog

Senior Service Engineer, Microsoft Visual Studio Team Foundation Service

Permissions required for Team Build Retention Policy in TFS2008

  • Comments 1

I got a question from one of our internal email lists today:

Our TFS build service is owned by a generic build account – domain\tfsbuild.  We have retention policy set up to retain a fixed set of builds.  The old builds were deleted when viewed via Team Explorer.  However, on the drop server, the builds are not deleted.  Apparently there’s an access issue when TFS attempted to delete the old builds. 

Someone told me that the TFS service account will need admin rights. Is this true?

Aaron from the Team Build team did a good job of explaining what was happening:

When TFS deletes build drops it first tries to have the build agent do the deletion, and then falls back to the AT.  Ideally, then, both the build service account and the AT service account would have full control to the root of the drop location.  This does not mean that these accounts need to be administrators on the box, however – that should not be a requirement. 

There should be errors in the event log on the AT whenever TFS tries to fully delete a drop – these should include the error that caused the deletion to fail.  You might have to get your friendly TFS administrator to have a look on the server and see if they find any such errors for the builds whose drops didn’t get deleted. 

Another is that the drop locations were in use when they got deleted – this is fairly common, typically resulting in everything on the drop but the handful of files that were in use getting deleted, along with whatever folder structure got preserved as a result.  You might have a look at your undeleted drops to see if everything is there, or just a few files.