TFS2012 LabDefault.11 template deploy scripts fail with “Team Foundation Server could not complete the deployment task”

Question

I am having security issues with lab management and standard environments.

I have TFS2012 update 2 installed in my domain \"DevDomain\". I have a separa

Answer 1

The above Pete Stensønes' solution works on my conditions.

But my scenario is to setup standard env on workgroup, but the tfs is in another domain. Just list my steps for your reference: Create local account on the following server: local lab service account - tfslab

1. tfs test controller server: create local tfslab account. Also configure the tfslab as lab service account in test controller configure console
2. tfs test agent server: create local tfslab account and add tfslab to local admin group. Also update Visual Studio Test Agent service and Visual Studio Lab Agent Service to run as tfslab.
3. tfs drop folder server: create local tfslab account. And add share read permission to tfs drop folder.

Answer 2

I have a workgroup environment without a domain, and it turns out that I had created the local account (.\tfslab) and had the TFS Test Controller setup with the use this account for lab management (.\tfslab) but I had forgotten to set each of the test agents services to run under the local machine account.

To troubleshoot this issue I highly recommend changing the 'Deployment script and arguments' to the following command:

cmd /c whoami

See additional troubleshooting steps here: http://social.msdn.microsoft.com/Forums/vstudio/en-US/f46dc491-87c2-4234-8566-99b25302020e/deployment-tasks-run-under-nt-authoritysystem?forum=tfsbuild

For folks who are running into issues with workgroup configurations (non-Domain) in the future don't forget to update the following services such that:

The Visual Studio Lab Agent Service 'Log On Account' is changed from 'local system account' to 'This Account' and specify the local machine account '.\tfslab'

The Visual Studio Lab Network Agent Service 'Log On Account' is changed from 'local system account' to 'This Account' and specify the local machine account '.\tfslab'

Answer 3

Have you configured your test controller for using lab service account?

If not try this:

Use account with appropriate permissions.

This account will be used to access to the build drop location, see

C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\QTController.exe.config

and search for "UseLabServiceAccountToAccessBuildDirectory".

Answer 4

OK I have eventually solved this with a little help from our network support chaps.

I require the agents on my "TestDomain" to be configured as interactive (as my next step is to run coded UI tests) when you do this, specifying a test lab account for communications, but a machine or domain account (in the "TestDomain") as the agent account (either being members of the local machine Administrators group) then the MTM lab process in "DevDomain" can deploy and configure successfully to the test machine in "TestDomain".

However this leaves the "Visual Studio Lab Agent Service" on the target machine in "testDomain" running as local system which is the process that actually executes your deployment script.

I could not find a permutation in the test machines "Test agent configuration" tool that let me change this whilst still running the agent as interactive, but you can just change the logon information for the service with the services control panel applet.

What I did was:

• Create a "test agent" local account on the "TestDomain" target machine and added that to the "TestDomain" target machine's local administrators group.

• I then mirrored this by creating a machine local account with the same name and password on the machine hosting our TFS drop share.

• I then granted read access to the share and file-system to that local account.

Now when the "devDomain" TFS server initiates a a build the script execution is run by the local "Visual Studio Lab Agent Service" its in the context of the new local "test agent" account and since there is a matching local account on the machine hosting the share it gets permissions granted, the share is readable, and hey presto it can run my script.

Answer 5

Using Visual Studio 2012 Update 4, and Team Foundation Server, on a one-way trust or isolated/workgroup network configuration, we have found an additional step is required. When running automated unit tests via the Build-Deploy-Test workflow, we have found that setting the lab service account is only part of the solution. In order to avoid Access is denied errors in the build, we also had to set the user for the Visual Studio Lab Agent Service.

This is what the services in the Services applet look like after setting the lab service account (in this example, ".\LabAdmin"):

Visual Studio Lab Agent Service         | Configures, monitors... | Running | Automatic | Local System  
Visual Studio Lab Network Agent Service | Sets network propert... | Running | Automatic | Local System  
Visual Studio Test Agent                | Provides distributed... | Running | Automatic | .\LabAdmin  

In order to fix the Access is denied error, we also had to run the Visual Studio Lab Agent Service under the lab service account:

Visual Studio Lab Agent Service         | Configures, monitors... | Running | Automatic | .\LabAdmin  
Visual Studio Lab Network Agent Service | Sets network propert... | Running | Automatic | Local System  
Visual Studio Test Agent                | Provides distributed... | Running | Automatic | .\LabAdmin  

After making this change, and restarting the services, the Access is denied error went away. This was repeated on two different target computers, at least with our configuration it appears to be a necessary step.