Change Password for TFS Build Service Account

The TFS Agent for 2015 or 2017 versions is a Windows Server machine that hosts the Service that allows to run Build and Release definitions for your code as part of the DevOps Process. It can run as a Windows Service and can be found by the name VSO Agent in the Services Snap-in. It uses a domain account to run the Windows Service which can be seen under the LogOn properties of the Service.

It runs VSOAgent.exe behind the scenes which is kept in the Agent folder configured for that TFS Agent e.g.


If at any point you require to change the Windows Service account details that was configured earlier due to may be a password change, the following command may help you.

Please note that Password should not be changed from the Services Snap-in as it may cause the Agent Service to break.

  1. Open Command Prompt in Administrator mode.
  2. CD to the directory e.g. as mentioned above C:\TFSAgent\agent\ . Make sure you’re one level above the folder where the VSOAgent.exe is placed else it’ll give error.
  3. Run the following command: .\Agent\VSOAgent.exe /ChangePassword
  4. Fill in the new Credentials as Prompted.
  5. Restart the Service VSO Agent from the Services Snap-in.

The Agent should now be running with the new Service account.

Release Management with TFS

Release Management is a service in VSTS Azure pipelines and TFS on-premise and an essential element of DevOps that helps you continuously deliver software. We can fully automate the testing and delivery of your software in multiple environments all the way to production, or set up semi-automated processes with approvals and on-demand deployments.

CI Build

Release definition defines the end-to-end release process for an application to be deployed across various environments.

You define the release process using environments, and restrict deployments into or out of an environment using approvals. You define the automation in each environment using phases and tasks. You use variables to generalize your automation and triggers to control when the deployments should be kicked off automatically.

You can create a deployment model on the basis of how you manually deliver the builds using build definition for different environments.

The below Release Definition shows different steps using PowerShell scripts that are modeled basis the manual process created for deployment.

Release definition


Creating a Release definition

Configure your environment:

  • Give the environment a meaningful name by clicking into the Default Environment name provided and enter one of your own e.g. DEV, QA, PRODUCTION.
  • Click on the ellipsis next to the environment name and select Deployment conditions…



Deployment Conditions


This is where we set up how we want our deployment to be triggered. It is here that we define what triggers the deployment of our release.

  • No automated deployment– deployment of the build artifacts will need to be undertaken manually with no automation
  • After release creation– this will deploy the build artifacts to the specified environment every time a new release is created i.e. Continuous Delivery.
  • After successful deployment on another environment– this will deploy the build artefacts to an environment after they have been deployed to another environment e.g. after every successful deployment to the STAGING environment deploy the build artefacts immediately to the QA environment

Use the first option if you are deploying to a production environment i.e. make the deployments to your production environment a manual exercise. Use the second option if you are deploying to a development testing environment as part of a Continuous Delivery pipeline. Use the last option if you want to push your deployments between different testing environments.


You may setup Approvals before the deployment to a particular environment using the Approvals Tab.



Configure a Queue and set demands

The demands may be System defined like “DotNetFramework” or you can set yourself like selecting Agent name.



General Tab



After configuring your environment, the next step would be to add task(s) which will be invoked when we want to deploy our build artifacts to the specified environment. The deployment task is the action that we want to happen when we invoke a deployment e.g. running a PowerShell script to start/stop App Pool, running database scripts, deploy the build on to a Virtual Machine or Azure instance.

Create Release

Create Release and select the build for which you would like to create a release in Dev environment and click on Create as shown below:


The successful build selected above will trigger the Automated Deployments based on the selections made for each environment.

Create build definition with TFS 2015 or newer

What is build definition?

A build definition is a representation of the automation process that you want to run to build and test your application. The automation process is defined as a collection of tasks. VSTS and TFS have a number of tasks to build and test your application. A build definition describes the details of what your build is supposed to do, and when it’s supposed to do it.

Build and Release are two of the DevOps services in VSTS and TFS that help you manage continuous integration and delivery of your applications.

Visual Studio Team Services (VSTS) and Team Foundation Server (TFS) provide a highly customizable continuous integration (CI) process to automatically build your Web, Mobile or Desktop application whenever your team pushes or checks in code. You can also Schedule builds on a specific date or time, recurring builds or manually queue a build.

You can add build tasks for .Net, Java, Node, Android, C++, xcode applications. Similarly, there are tasks to run tests using a number of testing frameworks and services. You can also run command line, PowerShell or shell scripts in your automation pipeline.

A basic build definition consists of 3 steps or build tasks which can be used with the Visual Studio template (this template requires Visual Studio be installed on the build agent):

  1. Visual Studio Build: This step builds the solution in the $(build.sourcesdirectory). This is the Source directory with the letter “s” under the Agent’s work folder. TFS gets all the files under this directory and builds the application under the bin folder. Provide the path to the solution that requires to be built. In case you need to build a web application, fill the msbuild arguments with: /p:DeployOnBuild=true /p:PublishProfile=<name of Publish profile>. Make sure the Publish profile is checked-in.BuildStep1
  2. Copy Files: This step copies the files from the source directory described above to the Artifacts Staging directory $(build.artifactstagindirectory) with the letter “a” under the Agent’s work folder. The Files Published for the Web Application can be found under bin\$(BuildConfiguration)\Publish folder.BuildStep3
  3. Publish Build Artifacts: This step Publishes the artifacts in step 2 to the Shared folder for which Network share path requires to be provided. Appropriate permissions are required on the folder to the same user that is running the Build Agent Service on the Agent machine. You can Publish the files copied in step 2 from the Publish folder above to the Network share path for continuous delivery pipeline. BuildStep4
Repository Tab

This tab lets you specify the Mappings under the Source “s” folder on the Agent machine as to how it should manage the downloaded source files locally. You can map each Server paths with a local path e.g. one Server path may be mapped to Application files and other Server path may contain PowerShell scripts which may need to be run in a different build task.

General Tab

This tab specifies some of the required demands that are defined as capabilities on the Agent machine like:

  • msbuild
  • visualstudio
  • vstest etc.

You can specify additional demands like choosing a specific agent by adding a demand as “Agent.Name”.

The Build Number format specifies the name of the folder under which queued build will be placed.

Variables Tab

This tab holds some predefined system variables and link to the entire list of it. You can also add your own variables which can be used in the build definition.

Triggers Tab

Specify whether to schedule the build, build with each check-in or with gated check-ins.

Retention Tab

Lets you specify the duration until which you’d like to keep the queued build.

History Tab

Shows the log of any changes made to the Build definition by which users and when.