Day 3: PowerShell and Team Foundation Server 2013 – Getting Started

Welcome to Day 3 of the “100 Days of DevOps with Powershell”! For background on our goals in this series, see Announcing the “100 Days of DevOps with Powershell” Series here at SCC.

I’m an Microsoft Application Lifecycle Management MVP, even though I work for a System Center company, so I tend to look at both sides of the DevOps equation. I am a strong proponent of Team Foundation Server and/or Visual Studio Online for version control and work item tracking related to your development projects. In this post I’m going to introduce you to working with Team Foundation Server using PowerShell. This will lay the groundwork for future posts, where we will dive into TFS, PowerShell, and DevOps in more depth, including using PowerShell as part of your automated build and release strategy. For this post, I’m going to assume you know the basics around Team Foundation Server. If you don’t, go check out some back columns of Inside TFS, or Professional Application Lifecycle Management with Visual Studio 2013.

The first thing you will notice is there are no out-of-the-box TFS cmdlets that ship with Team Foundation Server 2013.  However, if you install the Microsoft Visual Studio Team Foundation Server 2013 Power Tools Update 2, they come with some basic PowerShell cmdlets for interacting with TFS. Be careful when installing the power tools, as the cmdlets DO NOT install with a default installation.


You will want to perform a custom installation of the power tools, in order to install the cmdlets. Once the installation is complete, you’ll notice a new PowerShell Console is installed, as well as a Power Tools Help file.


The Power Tools Help file contains documentation related to all the Power Tools, including detailed information on the PowerShell cmdlets.


Most of the PowerShell cmdlets provide similar functionality to the tf.exe command-line utility. As such, the cmdlets deal mostly with version control aspects of Team Foundation Server.

Area Cmdlet Description



Displays information about changesets and lets you change the attributes, such as comments and check-in notes that are associated with a changeset. Commits pending changes in the workspace

Pending Changes


Adds, gets, or removes pending changes



Creates, gets, restores, or removes a shelveset



Displays information about the workspace. Retrieves a read-only copy of a file from Team Foundation Server to the workspace and creates folders on disk to contain the file

Version Control


Displays contents of child items under version control. Displays information or history of items under version control.

To get started using these cmdlets, you can either open the installed PowerShell console mentioned earlier, or manually add the TFS PowerShell snapin:

Add-PSSnapin Microsoft.TeamFoundation.Powershell

At this point, you can start utilizing the cmdlets. To start out simple, you can get some basic information about a workspace using Get-TfsWorkspace:

Get-TfsWorkspace –Path c:\ws\r2-09-tfs


In the above image, for a particular workspace path, we can retrieve the name of the workspace the computer the workspace resides on, and the owner.

One of the nice things about using the cmdlets (which is true of PowerShell in general) is they provide support for pipeline input, allowing you to string multiple commands together.  For example, let’s say we wanted to add a new file to a pending change in Team Foundation Server, and check that change in.  You can do that from the PowerShell console using the following command:

Add-TfsPendingChange –Add CalculatorData.txt | New-TfsChangeSet


In the above image, you have take the CalculatorData.txt file, added it as a Pending Change into Team Foundation Server, and then checked the change in. You get back the ChangeSet Number, which you could then use further down in your process chain, depending on what you are trying to accomplish.

However one drawback to the cmdlets is they are focused mostly on the version control system, with nothing allowing you to modify work items in the work item tracking portion of TFS. To do that, you are going to have to get your hands a little dirtier and write some PowerShell scripts. I’ll show you how that works in my next post. After that, we will dive into using PowerShell to help drive continuous delivery using Team Build, and wrap up this section of posts with a look at PowerShell DSC and TFS Release Management.  Stay Tuned!

Previous Installments

Below are previous installments in the “100 Days of DevOps with PowerShell” series.

One thought on “Day 3: PowerShell and Team Foundation Server 2013 – Getting Started

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.