2

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.

Community
  • 1
  • 1
Pete Stensønes
  • 5,595
  • 2
  • 39
  • 62
  • I have the same issue and many people more has that same issue. I already set the Lab service account like Elena suggested below but that doesn't work. I only got it to work when I add the user "domain\serverToDeployTo$" with read permission on the dropfolder. See my thread for more information. http://stackoverflow.com/q/16487581/801005 – LockTar May 17 '13 at 09:04
  • Side note: You do not need the "cmd /c". Powershell is an executable, not a shell command like DIR or MKDIR. – JamesQMurphy Sep 17 '14 at 21:41

5 Answers5

2

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.
Amitabha
  • 1,693
  • 2
  • 25
  • 42
1

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

If not try this:

enter image description here

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".

Elena
  • 1,928
  • 1
  • 15
  • 23
1

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.

Pete Stensønes
  • 5,595
  • 2
  • 39
  • 62
  • 1
    Hmmm, in my case I was not willing to change the account the "Visual Studio Lab Agent Service" is running as and as I said, using a Lab Service account solved the problem I have acessing the TFS drop share *from the LabTemplate* (cmd /c copy...). What I forgot to mention is that you have to update existing lab environments when you added the Lab Service account, see http://msdn.microsoft.com/en-us/library/ee712736.aspx. But it's right, it would not help you if you try to access TFS drop location when *running* your deployment scripts since they are run by "Visual Studio Lab Agent Service". – Elena May 17 '13 at 12:14
  • I am so excited, this is working - after searching for a solution for many hours. Literally, everything about TFS so far has not worked out of the box. Changing the service account is a hack, but.. since it works.. (also, the permission problem messages had so little meaning...) – Andreas Reiff Jun 21 '13 at 15:57
  • For us almost everything TFS has just worked - by default. Even the lab build works just fine UNTIL we had to utilise machines outside our trusted domains. This is as it turns out always a pain with windows as security becomes complex and always seems hard to diagnose. – Pete Stensønes Jun 21 '13 at 18:33
1

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'

Ian Ceicys
  • 11
  • 3
0

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.

Kevin
  • 11
  • 1