What is Lab Service Account?
Note: Cross posted from aseemb's blog.
Overview
Lab Service account is newly introduced in Visual Studio Lab Management 2010 RC release and is briefly discussed here and here. It greatly simplifies the account management of core components (test agent and build agent) used to run tests and deployment workflow. With lab service account, you are no longer required to run the agents under a local machine account as was the case in beta2 and are now free to run it under any account. (Note that even after this change, you should run the build agent under an account which has administrative privileges on the local box but it can be a domain account, system account like ‘LocalSystem’ etc.)
This lab service account is used for communication between test agent/test controller and build agent/TFS and is picked up automatically by virtual machines inside the environments. Therefore, you don’t have to worry about provisioning any permissions manually, or about running the agents/controllers under specific accounts. This account is not mandatory to use and you can continue using the local accounts as you were using in earlier releases but it is highly recommended to use lab service account as you don’t need to worry about permissions/accounts for the agents and can concentrate better on testing your application. This account should be a domain account and the instructions to configure it are mentioned here.
Once you have configured the lab service account for your team project collection, you can view the configured account under the ‘Lab Management’ tab of team foundation admin console as shown below.
Which system components use this account?
This account is used by test agent and build agent running on ‘virtual’ lab environments on which testing and/or workflow capability is enabled.
On testing enabled virtual lab environments, test agent uses this account to communicate with the test controller. This account is only used for the communication channel between test agent & test controller and not used to run the test agent. Test agent continues to run using the account under which it is configured using the test agent configuration tool and only the communication channel between the agent and controller uses this lab service account. So the execution of ‘tests’ and collection of logs does not happen under the lab service account and happens under the account configured using the configuration tool.
Similarly on workflow enabled virtual lab environments, build agent uses this account to communicate with the team foundation server. This account is only used for the communication between build agent and team foundation server and not used to run the build agent. Build agent continues to run using the account under which it is configured using the administration console and only the communication channel between build agent and team foundation server uses this lab service account.
Additionally during execution of the deployment workflow, the build agent configured via workflow capability accesses the build drop location using the lab service account. The execution of the deployment script still happens under the account configured using the administration console and only the drop location is accessed using the lab service account as shown below.
As you would have noted from the above picture before execution of each deployment script, build agent configures its logged on session to access the drop location using the lab service account and on completion of the script, it removes that configuration.
What Permissions are granted to this account?
At the time of configuring the lab service account, the minimum set of permissions required for the agent communications to work are granted automatically. With these permissions, test agent will be able to communicate with the test controller and build agent will be able to communicate with team foundation server & run the default lab deployment workflow. Note that you still need to grant read permissions to the lab service account on the build drop location and they are not granted as part of the configuration.
The build agents on the lab machines are not meant to compile the sources and are meant only for execution of deployment scripts, so the permissions which are granted to ‘non-lab’ build agent are not same as the lab build agents. For lab build agents, there is no need to have read permissions on the source control system, so as part of the configurations the lab service account is denied all permissions on source control artifacts in the project collection.
To summarize, as part of configuring the service account following permissions are granted/denied automatically as shown below: -
1. Addition of the lab service account to the collection level ‘Project collection Build service accounts group’.
2. Explicit deny on source control artifacts in the project collection.
Customized workflow
Lab management ships a default workflow template which you can use to build your sources, deploy them on a clean lab environment and run tests on it. This workflow has been discussed here. In most of the scenarios, this workflow will be used as it is and you will not have to any modification in it but in some scenarios the default workflow might not suit your needs and you may have to customize it. This workflow is fully customizable and is discussed here and here.
As part of this customization, you may have to create some custom activities and then use them in the template. Once you have created those activities and want to use them in your template as mentioned here, you should ensure that build agent, communicating using the lab service account, can access those activities. Since these activities need to checked-in to the source control system as custom assemblies, you need to ensure that lab service account has read permissions on the path in which custom assemblies are checked-in.
Source control permissions/Custom assemblies
You can grant permissions to lab service account using the ‘tf permissions’ command. For example:- To grant read permissions to lab service account ‘mydomain\labAccount’ on path ‘$/MyProject/CustomAssemblies’, you should execute a command similar to following one.
C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE>tf permission /user:mydomain\labAccount /collection: https://aseemb-tfs10:8080/tfs/Collection0 /allow:read $/MyProject/CustomAssemblies
Access drop location under build agent account
As discussed above, build drop location is accessed using the lab service account. But in case you don’t want to access it under the lab service account and want to access it under the build agent account, then you can do that by customizing the template. In the template, there is an activity called ‘RunDeploymentScript’ which is used to execute the deployment scripts. This activity exposes a property named ‘SharedLocationForNetUse’ which defines the location that should be accessed using the lab service account.
<mtlwa:RunDeploymentScript DisplayName="Running Deployment Script" ScriptDetails="[scriptDetails]" ThrowOnError="True" SharedLocationForNetUse="[BuildLocation]" />
To not access the drop location under lab service account and access it under the build agent account, you should either set the value of this property to null ({x:Null}) or remove this property from the template as shown below.
<mtlwa:RunDeploymentScript DisplayName="Running Deployment Script" ScriptDetails="[scriptDetails]" ThrowOnError="True" SharedLocationForNetUse="{x:Null}" />
Access other locations using lab service account
To access location other than the build drop location under lab service account, you should change the value of property ‘SharedLocationForNetUse’ from its default value ‘[BuildLocation]’ to the desired location. For example to access \\aseemb-dev\scripts directory under lab service account, you should have something like this.
<mtlwa:RunDeploymentScript DisplayName="Running Deployment Script" ScriptDetails="[scriptDetails]" ThrowOnError="True" SharedLocationForNetUse="\\aseemb-dev\scripts" />
Best Practices
1. You should provision 2 dedicated accounts to be used as lab service account and then keep switching between them whenever the configured account reached its mid life. This will increase the availability of the testing/workflow capabilities by reducing the chances of communication failure because of expired account. More details on this are mentioned here.
2. On updating the password for lab service account or on changing the service account itself, you should run a command-line (TfsLabConfig UpdateServiceAccountOnDeployedEnvironments) to update the account on all the existing environments. This will also reduce the chances of communication failure because of old account present on the lab machine.
3. The credentials for lab service account(s) are not stored very securely on the lab machines, so the lab service account should be granted minimum permissions on your network and should not be used to run test controller, build controller, team foundation server etc as those service accounts need more permissions on team foundation server.
Note: - The lab service account and the test controller service account should not be same because it can lead to communication problems between test agent & test controller in a topology where test agent is not joined to the same domain as the test controller. This is a known issue for RC and is documented in the trouble shooting guide.