TFS2012 LabDefault.11模板部署脚本因“ Team Foundation Server无法完成部署任务”而失败

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 separate build/lab machine also in "DevDomain" on which both a build controller, build agents and a test controller for the same collection "CollectionA" are installed.

Automated builds work just perfectly.

I have deployment target PCs in "DevDomain" and in "TestDomain" (more on that later).

To take this to the next level, I want to now automatically deploy the TFS build agent constructed software to test rig machines; specifically I want to have a deployment script uninstall the existing product, copy the updated installer onto the target PC and then install it.

My first foray was to define a standard environment in my "DevDomain" and get the deployment part of a lab build working within the same domain.

This worked. Here is what I did;

The automated build (using the DefaultTemplate.xaml process) creates a MSI file I want to use for the deployment, and a PowerShell script which I want to run to orchestrate the deployment. (the script simply attempts to run the MSI via msiexec to uninstall, copy the new version locally then run it via msiexec to install the new copy). The automated build happily makes both these artefacts and puts them in the defined TFS drop share.

In order to go about this I have:

• Created a new standard lab environment with a single machine (desktop client role)
  • The lab manager successfully deployed the agent to this PC
  • the agent is running interactive and showing its online.
• Created a new build definition using the LabDefaultTemplate.11.xaml workflow.
  • referenced the above lab in the configuration
  • referenced the latest output of the automated build in config
  • specified the build output PowerShell script (via the $(BuildLocation) macro.

This deploy tab of the build specifies the following script to be run on the machine sin the lab with "Desktop Client" role:

cmd /c powershell.exe "$(BuildLocation)\DeployGuiToLabWorkstation.ps1" "$(BuildLocation)"

This works.

Note that I am configuring test agents to run as interactive processes as my ultimate aim after the deployment works is to drive coded UI tests on these labs.

The problems start when trying to deploy to a machine in a different domain Now to make this more realistic I now need to define a standard lab environment for my QA machines, which are in a different domain; "TestDomain".

The domain "TestDomain" has a trust relationship with the domain "DevDomain". There is no reciprocal trust between "DevDomain" and "TestDomain"

Again the test manager lab centre defined this OK and deployed the agent, and the agent reported itself online to my test controller.

Now when I change the lab build to reference the new standard environment (on "TestDomain") the deployment fails with this error;

Exception Message: Team Foundation Server could not complete the deployment task for
machine '10.7.70.71', script 'cmd' and arguments '/c copy \\*buildmachine*
\TFS_Drop\...\DeployGuiToWorkstation.ps1 C:\GuiDeploy'. (type LabDeploymentProcessException)

In order to diagnose this I have modified the lab deploy script to be:

"cmd /c powershell whoami"

And according to the logs the process is being run as "nt authority\\system" and not the account the lab environment specified for the test agent.

This explains the script error; PowerShell on the target PC cannot access the TFS drop share, but since this account is a local machine account I cant possibly grant permissions to the machine account of a PC in "TestDomain" to a share and NTFS folder on a machine in "DevDomain"

So how can I grant permissions on the "devDomain" share/filesystem to a "System" service account from a machine in "TestDomain"?

or

How do I get the test agent (running as a local machine administrator) to execute the deployment script in its own account context rather then this machine system context?

I am stumped!

---

EDIT : It seems that the test agent UI runs in the account you specify, but when you configure it that way it leaves the service "Visual Studio Lab Agent Service" running as local system, you can manually change this in services, to a more appropriate domain account and that account is then reflected in the PS "whoami" results.

I am now investigating using a TestDomain account for the service that mirrors a "DevDomain" account so I can set share permissions appropriately.

---

This is a similar scenario to TFS Lab management Deployment Scripts but since that was side-stepped by using tests and test settings, and I specifically want a resolution of the deploy part I thought it worth asking the question.

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

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 3

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 aa 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 4

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 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 | 
Visual Studio Lab Network Agent Service | Sets network propert... | Running | Automatic | Local System  
Visual Studio Test Agent                | Provides distributed... | Running | Automatic | 

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 | 
Visual Studio Lab Network Agent Service | Sets network propert... | Running | Automatic | Local System  
Visual Studio Test Agent                | Provides distributed... | Running | Automatic | 

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.