Connecting TFS GIT in LINUX

Problem –

Developers were getting issue when they were trying to do GIT operation (like clone) in TFS from LINUX (CentOS). They were getting certificate issues.

Resolution –

Solution is to generate SSH key in LINUX and set the same in TFS. With it, Git in LINUX is able to handshake with TFS.

Here are the steps that needs to be performed in LINUX –

1. Generate SSH key. Run the below command - 

      ssh-keygen -t rsa -C "emailID"

Note – “emailID is your email ID.

2. Run the below command to get the key and copy the output key as shown below –

      cat ~/.ssh/


Go to the TFS web portal and follow the below screens –

3. Click on person icon and select Security option.


4. Below screen will appear. Select “SSH Public Keys” option and click on Add. It will ask for the key and enter the key, you copied in step 2 above.


Now go to the LINUX environment and try to do git clone operation. It should work.

                      ——–End of Article——

TFS–Automated Builds–Agent Workspace–Application folder

In the current scenario, when we need to build any application through build definition in TFS, it downloads all the sourcecode/components in the Agent’s workspace in a folder with a “digit” as a name of folder instead of the application name. For example, in case of xxxBillSplit application, it downloaded the source code in folder “7” under the Agent workspace.

For many applications like xxxBillSplit, it is perfectly ok but for application like XYZ where we have cross team project references, it is not working and getting failed.

To address this issue for complex applications like XYZ, following changes can be done –

  1. Under Agent’s workspace, a folder with the name “SourceRootMapping” get created as soon as agent builds the first application. This is single folder for all the applications agent is building. Under this folder, there are folders for all the build definitions with the collection id (GUID) as name a shown below – image
  2. Under GUID folder, there is a folder with the name as build definition ID. Both the above information about GUID and build ID can be found from the build definition as shown below –image
  3. Under the build ID folder, there is json file called “SourceFolder.json” which contains information about the builds as shown below – Please note “7” referencing in many places that I have shown in highlighted box –image
  4. Replace build id (7 here) as highlighted above with the application name as shown below.image
  5. Once done, rebuild the application. Folder with the application name will be created. You can now delete the folder with ID (7 here) as shown below – image

This activity needs to be done for all the team projects and it is one-time activity. Once done, backup of this folder (SourceRootMapping) can be taken and in case of new server/new agent/new workspace, this folder can be restored to implement the changes.


                 ————End of the Article————-

Automated Team Project Creation and Assigning User Group to Readers Group

Suppose there is a requirement to create Team projects through command line and once created, a particular User group needs to be added to one of the inbuilt user group in TFS (say Readers group).

I wrote below PowerShell script to implement it.

Requirements –

1) TFS power tools should be installed on the system.

2) Visual Studio should be installed.

Script Code –

   Script to create team project and to add user group to the Readers group
   This script will create a Team Project and will then add user’s group to the TP’s Readers group. On running the script, enter the information as asked to enter.

#Script Name – CreateTPAndAddGrptoReaders.ps1
#Creator – Mohd Aslam Ansari
#Date – 22-Dec-15
#Updated – First Version
#References, if any

$TeamCollectionURL = Read-Host "Enter Team Collection URL (Ex. https://[TFSServer/tfs/POCCollection/):"
$TeamProjName = Read-Host "Enter the Team Project Name:"
$ProcessTemplate = Read-Host "Enter the process template (Agile/CMMI/Scrum):"
$UserGroup = Read-Host "Enter the User group that needs read access with domain (Ex domain\group):"

tfpt createteamproject `
/Collection:$TeamCollectionURL `
/teamproject:$TeamProjName `
/processtemplate:$ProcessTemplate `
/sourcecontrol:New `
/Validate `

tfpt createteamproject `
/Collection:$TeamCollectionURL `
/teamproject:$TeamProjName `
/processtemplate:$ProcessTemplate `
/sourcecontrol:New `

cd "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE"
.\TFSSecurity.exe /g+ [$TeamProjName]\Readers n:$UserGroup /collection:$TeamCollectionURL

[void] [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.VisualBasic")
[Microsoft.VisualBasic.Interaction]::MsgBox("Team Project created with the Name – " + $TeamProjName + ". " + $UserGroup + " added to the Readers group.","OKOnly,SystemModal,Information", "Success")


For more information on TFPT command, refer to PowerShell help by typing tfpt /?

—-End of Article—

TFS/RM PowerShell policies

Lets discuss the PowerShell execution policy scenario when we are using Microsoft TFS and/or RM(Release Management).

Before running any PowerShell script, first step is to define an execution policy. How to define it? See below:

First see what is the existing policy in place by running Get-ExecutionPolicy cmdlet. By default, it will be “Restricted” as shown below:


Windows PowerShell has four different execution policies:

  • Restricted – No scripts can be run. Windows PowerShell can be used only in interactive mode.

  • AllSigned – Only scripts signed by a trusted publisher can be run.

  • RemoteSigned – Downloaded scripts must be signed by a trusted publisher before they can be run.

  • Unrestricted – No restrictions; all Windows PowerShell scripts can be run.

Now, we have to select one best suited to our Organization. From the above list, most secured option would be “AllSigned”. How to set it? See below:

Run Set-ExecutionPolicy with “AllSigned” argument as shown below: It will set the policy.


With this policy (AllSigned) in place, we need to sign all the PowerShell scripts before running them in the target machine.

Now the question arises is that –

  1. What will happen to the PS scripts that TFS/RM generates and runs internally to implement particular task? We cannot sign them as we cannot see them. This is important to answer and understand because TFS and RM, all does all the activities using PS scripts internally.
  2. As well as many times, we writes PS scripts to do some specific task from TFS and RM, do we need to sign them?

To answer the first question, Microsoft says that the execution of the PS generated internally will be unaffected by the policy you set at machine or user account level. They will be executed under “ByPass” policy which will not take your machine’s policy into account. It is possible because the context under which the script will run, will be administrator of that server and MS assumes that since they have written the code themselves, so it is secure and can be executed with bypassing the already set policy. Point to be noted here is that the policy will be bypassed only for that session under which the script is executing and it will not impact the existing policy in any way. One can run and use the existing policy for any other script execution at the same time.


To answer the second question, the PS script that user will write and will be passing to the Remote PowerShell task, when that script is executed it will get executed with the ByPass Policy as well. Microsoft assumes that you being developer of the script, will write the secure code and execute the script with proper security. If you want your script to run using the particular policy like in our case “AllSigned”, you can define in your user script (say, at the top line of the script) to run under a different execution policy (For example, Set-ExecutionPolicy AllSigned –Scope Process), then that policy will be used for all the subsequent script invocations, that will get invoked from your main script which you passed in the task instead of the ByPass Policy that we set.

—End of Article—

Agent based Release – How to make it secure

Here is the scenario….

This is regarding MS Release Management 2015. If we set a release (QA –> Stag –> Prod) and in each environment, we have some specific sensitive information that needs to be replaced in the config files. Now, our understanding is that we have to create variables in components and it will replace the information accordingly in the particular environment but the value needs to be written in the workflows at the time of the release creation. Release will be created by QA team and we don’t want them to see the sensitive information of the Production. How to achieve it? How can we avoid writing sensitive value at the beginning? Can we have security around it?

Here is the solution to this scenario:

Follow the below steps for Agent Based release templates.

  1. For every environment like Staging/Production, create a Group. Let’s say a group for SQA as shown below. It can be added from Administration –> Manage Users.
  2. From the security tab, add the stage and the type of permission like “Edit Value…”. Suppose we have added stage as “QA” and we gave “Edit Values and Target servers” rights then all the members of SQA group can edit the values of the variables in that particular environment.clip_image002
  3. Configure Variables for different stages as “Encrypted” type. To do so, go to Configure Apps –> Components –> Configuration Variables clip_image002[5]
  4. Finally, the values of the encrypted variables can be set in each stages by the respective teams. Please note that the values needs to be set before initiating the release. Once the release will be started, it cannot be changed. This is also controlled by the security set at step 2 above.image –End of Article–

Config file data changes during runtime in RM

In the real business scenario, it is always the requirement that every environment (QA, Stag, Prod etc) have its specific data mentioned in the different config files. As an example, the most common requirement is that every environment have its own database connection information in the config file.

Now the question is, how to get it changed/updated when release will go to the particular stage?

Here are the steps that can help us implementing it :-

  1. In the Release Management Client, go to the tabs – Configure Apps > Component and select the required component: image
  2. Double click the selected component. It will open it. Select the tab “Configuration Variables”. Add the variable by clicking the Add button. Select the required Variable replacement mode from the dropdown list. Finally select the File Extension filter which will be considered for replacing the added variable. Here in this example, I have taken web.config and so File Extension filter will be *.config. image
  3. In the release template, add the above changed component and set the appropriate value for the variable. Copy the component into all the configured environments and change the value of the variable accordingly. image
  4. Save and close it.
  5. Finally go to the visual studio and edit web.config and add variable in it with two underbars both at start and at the end. Example, in our case, we added username=__USERNAME__image
  6. Trigger the release and it will replace the value of __USERNAME__ with the one defined in the components in RM for the respective environment.

–End of Article–

Trigger Agent Based Release in RM from vNext Build in TFS 2015

In Continuous integration (CI), one has the requirement to trigger release of the build artifacts to the intended environment. In TFS 2015 and RM 2015, it can be achieved using the below steps:

  1. Release in the release management needs to be configured. I am not going to cover how to configure it here in this article but for the triggering perspective, below setting should be done in it: image  
  2. On the build machine, install and configure the Release Management 2015 client. It should be configured successfully.image
  3. In the Release Management Client, add user under whose context the vNext build agent is running. For doing this activity, Go to Administration > Manage Users and click New to add the user.
  4. Now in the vNext build definition, add a new Task of type “Command Line”: image
  5. Once this task is added, Name it and enter the below data in it:      
    Tool ReleaseManagementBuild.exe
    Arguments –rt ‘MyReleaseTemplateName’ –pl ‘MyPackageLocation’ –ts ‘ReleaseTargetStage’ 
    Example –  
    Tool C:\Program Files (x86)\Microsoft Visual Studio 14.0\Release Management\Client\bin\ReleaseManagementBuild.exe
    Arguments -rt ReleaseTemplateTest -pl \\DropServer\TFS_Drop\$(Build.DefinitionName)\$(Build.BuildNumber) -ts QA  


  6. Enable Continuous integration (CI) from the Triggers tab of the build definition. image

Now once the above steps are done, agent based release can be triggered from the vNext based build definition in TFS 2015 and you will get below information from the build console: image

——End of the Article——