Configure Release Management for Visual Studio 2013

In this post, I’m going to walkthrough how to set up Release Management for the first time. This will include installing and configuring the Release Management Server, the Release Management Deployment Agent, creating an environment, and deploying our favorite application from Microsoft, Tailspin Toys.

Release Management Server

Much like the installers for the rest of the Visual Studio suite, we can just run the setup executable, and all the configuration steps occur after the installation. Because of this, I’m going to skip over the installations as they are merely agreeing to the fine print and clicking Install. Once installed, run the Release Management Server for Team Foundation Server 2013. This will pop up a window that lets you configure which account to run the service as, which web service port to use (1000 is the default port), and which database server to use.


Figure 1: The configuration for the Release Management Server

Fill out the account that you want to run the server as, which database server to use (I used my TFS database server), and then click Apply Settings.


Figure 2: Configuration summary of a configuration succeeding for Release Management Server

The configuration summary, and whether or not the configuration succeeded, will then be displayed. The configuration dialogs can now both be closed.

The next thing we need to do is connect the server to TFS. To do so, install the Release Management for Visual Studio 2013 client (it is as simple as accepting the terms and clicking install). Once installed, go to the Administration tab and select the Manage TFS link.


Figure 3: Administration –> Manage TFS –> New to create a new TFS connection

Click the New button to bring up the TFS configuration window.


Figure 4: Verify the connection and click Save & Close

Fill out the appropriate information, and once done click the Verify link.


  • The account you use here must be a part of the Team Foundation Service Accounts group. The only way to add a user to that group is to use the command line tool TFSSecurity.exe. The executable is located here:
    • C:\Program Files\Microsoft Team Foundation Server 12.0\Tools
  • The command to run is:
    • tfssecurity /g+ “Team Foundation Service Accounts” “<account>” /server:http://localhost:8080/tfs
    • <account> is the account you want to add to the Team Foundation Service Accounts group

Once verified, you can Save & Close the configuration dialog. This configured the connection to TFS itself. The Release Management server is now ready to go. The next thing we need to do is install the Release Management Deployment Agent to the machine(s) we want to deploy to.

Release Management Deployment Agent

Again, much like the Release Management Server, the deployment agent is installed by merely accepting the terms and clicking the install button. The configuration occurs post install, so when the install completes, open the Microsoft Deployment Agent 2013 to configure it appropriately.


Figure 5: Configuration page for the Microsoft Deployment Agent 2013

Again, fill out the account to run the agent under as well as the URL for the Release Management Server (which we specified in the previous section) and click Apply settings.


Figure 6: Configuration summary of a configuration succeeding for Microsoft Deployment Agent 2013

We are now ready to add the server to the Release Management Server through the client application. Open the Release Management client, go to the Configure Paths tab, and click on the Servers link.


Figure 7: Scanning for new servers to add to the Release Management Server

Click the drop-down for New and click the Scan for New button. This will show the server that we just installed and configured the agent on.


Figure 8: Choosing the server to register with Release Management Server

Select your new server and then click Register & Close. The deployment server has now been added to your Release Management Server and can be used to deploy different things to.


  • I got a Deployer Error after this registration.
    • Deployer Status: Offline
    • Deployer Error: Deployment Agent has not communicated with the Release Management server. It may not have been installed yet.
  • Reapplying the configuration settings to the Microsoft Deployment Agent 2013 fixes this issue. After reapplying, click the Refresh button on the Servers page and the error should go away.


Figure 9: One server registered with Release Management Server

The deployment server now has an agent running on it, and has also been added to the Servers available for the Release Management Server.

Stage Types & Technology Types

Stage types are what we define as the stages the deployment must go through. For instance, we may have the stages Dev, QA, and Prod that a deployment could go through. Another set of stages might be, Dev, QA, UAT, PreProd, and Prod. These are totally dependent on what stages your application must go through in order to get to production. For my environment, I’m going to create the following Stage Types: DEV, QA, and PROD.

To do this, open the Release Management client, go to the Administration tab, and then click the Manage Pick Lists link.


Figure 10: Add new Stage Types to Release Management

Click the Add button to add new stage types, and then click the Save button to save them.

Technology types are types of technology that can be associated to a server that is registered in Release Management. These are useful so one can determine where a certain package can be deployed to, without have to hard-code the correct path into the automation. For instance, I can specify IIS, ASP.NET, MVC 4, and SQL on one machine and know that, that machine has those dependencies on it. Again, these are manual and requires management and are not tied to any specific configuration on the server themselves. You can easily associate SQL to a server that does not have SQL installed on it.


Figure 11: Technology Types that have been added to Release Management

To add Technology Types, select the Technology Type on the left and use the same steps that were used in adding Stage Types.


Now, we need to set up an environment in order to deploy Tailspin Toys. I’m only going to create one environment for now – DEV – in order to start my Release Management process. To do so, open the Release Management client, go to the Configure Paths tab, and select the Environments link.


Figure 12: Create a new environment

Click the new button to create a new environment. We are going to want to use the server that we previously registered.


Figure 13: Configuring an Environment

Enter the details that you want to have associated with the Environment. This includes the name, owner, description, notes, etc. Once done, click the Link Existing button to show existing servers that you can add as part of that environment. Select the server that we added in the last section and then click the Link button.

Now, click the Supported Technology Types tab to select the technologies that are available on this server.


Figure 14: Selecting technology types for a specific environment

The third tab, Stage Type Security, will determine which stage(s) the environment can be used for.


Figure 15: Selecting the right Stage Types for my DEV environment

This is my going to be my DEV specific environment, so I’m only going to allow it to be used for the DEV stage type. I’ve unselected All Stage Types and added a new one for DEV and selected it.

Once everything has been configured correctly, we can click the Save & Close button. We have created an environment called DEV which is linked to a server, has specific technologies in it, and can only be used for the DEV stage type.

Release Paths

Release paths are the paths through the different stages an application must go through. This is where we define a release path for an application and are able to put in information around:

  • The stage
  • The environment
  • Whether the acceptance step is automated and who is the approver
  • Who is the owner of the deployment step
  • Whether the validation step is automated and who is the validator
  • As well as putting zero, one, or many approvers for the DEV step.

To create a release path we need to open the Release Management client, go to the Configure Paths tab, and then select the Release Paths link.


Figure 16: Create a new Release Path

Click the New button to open up the dialog to create a new Release Path.


Figure 17: Configuration for a Release Path

Give your Release Path a title, description, and then add the stages that you want. For each stage, you need to specify the stage (which is defined by the Stage Types we created earlier), the environment (which is dynamically filled depending on which stage you choose), who the approver is, who owns the deployment, who is the validator, and whether, or not, the acceptance and validation steps are automated.

You will note that I only have one stage. This is because I’m only going to be setting up my DEV stage with my DEV environment. Because I specified that my DEV environment can only be used for my DEV stage, the environment will show up if I select a stage that is not DEV. You can use the DEV environment for every stage, or you can use different environments.


Components are the different packages that will be deployed using Release Management. For instance, I have a web site and database that I want to deploy for Tailspin Toys. Therefore, I have two components (Tailspin.Web and Tailspin.Schema). We will create components that will target these different components and specify how to deploy them.


The first thing we will be doing is deploying the database. Since the Tailspin Toys project is already a SQL Server Database Project, a dacpac is already created during an automated build. Here’s more information on data-tier applications. In essence, dacpacs are artifacts that can be used to deploy databases. They will automatically create the database if needed, or run an upgrade on a database that already exists. The Tailspin Toys database project has a post-deployment script that runs to import a bunch of data for the website itself, so we are going to be recreating the database on every deployment.

To set up a component for Tailspin.Schema, go to Configure Apps, Components, and then click New.


Figure 18: Component information about Tailspin.Schema

We will want to fill out the name of the component (Tailspin.Schema will be the name of my component) as well as where to get the package. All of the Tailspin Toys components are being built together, so I chose Builds with application and then use the root folder as the path to the package (to choose the root folder, merely put a ‘\’ into the text box).


Figure 19: DACPAC Database Deployer configuration

The next thing we need to do is to choose the deployer tool and set up the arguments that need to be filled out when running the deployment. For Tailspin.Schema, I chose the DACPAC Database Deployer which will deploy the dacpac using sqlpackage.exe. Most likely, you will not need to modify anything beyond choosing the DACPAC tool, but since there is a post deployment script that runs, and will fail if there is already data in the database, I added a property to the deployment to create a new database during the deployment (essentially drop the old one and create a new one). To add a parameter, you merely need to put two underscores before and after the parameter name in the Arguments window. This is a wildcard that Release Management picks up to automatically make it a parameter.

Once done, we can hit Save & Close. This will save the Tailspin.Schema component, and we can now move onto the Tailspin.Web component.


The web component of Tailspin Toys will be done a little differently than the database portion. Go ahead and create a new component for Tailspin.Web by going to Configure Apps, Components, and then clicking New.


Figure 20: Component information about Tailspin.Web

Again, we are going to give it a name (Tailspin.Web will be the name this time) as well as where the package will be. By default, web sites are going to be dumped into \_PublishedWebsites\<WebsiteName> during a team build. So, Tailspin.Web is going to be located at _PublishedWebsites\Tailspin.Web and it will be part of the Builds with application text box. Once done, we can move onto the Deployment tab.

1-30-2014 10-40-36

Figure 21: Deployment configuration for Tailspin.Web

This time, the tool will be the XCopy Deployer. It comes with only one argument by default, and it will be the only argument that we will need. The installation path will be filled out when we are creating our release template. This is all we need to define in order to be able to deploy Tailspin.Web as a component. Once done, go ahead and click Save & Close.

Release Template

The release template is really tying everything else we have done together. This is where we choose our release path we want our releases to move along, as well as the workflow in which we want to deploy our components. To create a new Release Template, go to Configure Apps, Release Templates, and then click New.


Figure 22: Release Template properties for Tailspin Toys

The first thing that pops up is the properties for the new release template. Fill out the name, choose the release path that you want (I created TailspinToys as a release path earlier in this blog post), and then choose the build definition that the packages will be pulled from. Once you have chosen your configuration, click the Create button. This brings us to an empty workflow designer page.


Figure 23: Adding components to your release template

We will need to add the components we just created into the toolbox for this release template. Right-click on components, select the correct components, and then click the link button. This will add the components we want to deploy to the toolbox so that we can drag them into the workflow.


Figure 24: Drag and drop the server and then component into the workflow designer

We first need to drop the machine we want to deploy to into the workflow designer. This will give us the ability to run activities on that machine. After that, we can drop the Tailspin.Schema component onto the server (we want the database to be deployed before the website is deployed). Once the component has been dropped into the workflow, we can double-click it to get to its parameters (the ones we defined in the components section of this blog).


Figure 25: Tailspin.Schema’s configuration variables

This is where we put in the name of the dacpac file, what is the server name we are deploying to, what is the database name we want to deploy the dacpac to, and whether or not we want to create a new database. Once done, we can click the Deployment Sequence on the breadcrumbs at the top left of the workflow designer to get back to a global view of the workflow.

Before we deploy Tailspin.Web, we want to ensure that there is a web site and application pool for us to actually deploy to in IIS. To do so, we are going to drag and drop the Create Application Pool and Create Web Site under the IIS node in the toolbox into the workflow, after the Tailspin.Schema component. Note that by using the create rather than the configure activities, they will first check to see if the app pool or web site already exist and only configure them if they do exist. Again, we need to fill out a few parameters for these activities.


Figure 26: Application pool configuration variables

For the application pool, I leave everything default and only give it a name of Tailspin.Web.


Figure 27: Web Site configuration variables

For the web site, I give it the application pool’s name, the name of the site (which will match the application pool’s name), a port number, as well as the physical path for the web site (note that I will also define this in the component configuration for Tailspin.Web anyway). Once we have created the application pool and the web site, we will want to deploy Tailspin.Web itself. Again, drag and drop the activity onto the workflow designer and double-click it to define its parameters.

1-30-2014 10-44-10

Figure 28: Tailspin.Web configuration variables

The configuration variable needed here is merely the Installation Path. This will be the path that we defined as the PhysicalPath for the website we created in IIS (our previous activity in the workflow).


Figure 29: Tailspin Toys deployment sequence for the DEV deployment

Once everything is said and done, we should now have a sequence that looks something like the above screenshot. We should now be able to click Save and then click New Release.


Figure 30: Starting a new release

Give the release itself a name, and then click the Latest link to poll the latest build from the build definition we specified for the release template itself. You will be brought to the page of the release you just created where it will show you it is currently in progress. If the release does work, it will be automatically updated and show the status of Released.


Figure 31: Successful deployment of Tailspin Toys

Once this is done, we can go verify that it is working by navigating to http://tupper-tfs:5000 and Tailspin Toys should appear.


Figure 32: Tailspin Toys now running on http://tupper-tfs:5000



Please note that this is a very simple deployment. I have almost no error checking, and absolutely zero rollback if things don’t work. This is very much a happy path deployment using Release Management, and should be added to for actual deployments. There are specific activities in Release Management that will help you complete rollbacks when releases fail.

About the Author:


  1. Mehdi March 31, 2014 at 10:08 am


    I have been following your tutorial and it all went fine until I used the xcopy tool (Figure 20 above) in my workflow. (Without it, it runs fine)

    The deployment fails miserably and in the event viewer in my deployment machine, I found the following error message:

    Message: Invalid path: rnrn
    Server stack trace:
    at System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter)
    at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
    at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
    at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
    at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

    Exception rethrown at [0]:
    at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
    at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
    at Microsoft.TeamFoundation.Release.Data.FileTransferServiceRef.IFileTransferService.DownloadFile(DownloadRequest request)
    at Microsoft.TeamFoundation.Release.Data.FileTransferServiceRef.FileTransferServiceClient.DownloadFile(String& FileName, Stream& FileByteStream)
    at Microsoft.TeamFoundation.Release.DeploymentAgent.Services.Deployer.FileDownloader.Download(String serverfilePath, String serverTempPath, String destinationFolder)

    My environment/config is:

    Release Management for Visual Studio 2013 configured inside a domain.
    The Deployer is running on a remote to the domain server and connecting via a publically facing http endpoint using Shadow accounts successfully
    The Drop Location Access on the server configuration is set to ‘Through Release Management Server over HTTP(S)’

    My xcopy component in releasemgt is configured to the same way as in your tutorial. Is there any logs I can look at in releasemanagement or in the deployer agent to get a bit more insight on whats going on?

    Any idea on what might be going on ?
    Thank you;

  2. James Tupper April 1, 2014 at 7:47 am

    This looks along the lines of the same issue in this MSDN forums post:

    Some additional logs can be found here:

    Does that post look similar to the issues you are seeing?

  3. Mehdi April 1, 2014 at 9:32 am

    Hi James,

    The link you pasted is more of release management configuration issue.
    My problem is past that and it’s more when using release management to deploy and run the release workflow during a build.
    As mentioned previously, my Release Management and my Deployer are running in different domains (I went through all the setup with the Shadow accounts successfully).

    Now my release workflow works fine for simple workflows and as long as I dont use the xcopy tool as it is done in this tutorial. When using the xcopy tool in my custom component (just like in the tutorial), the workflow fails with the error:
    ‘After 0 files transferred successfully, file xyz was unsuccessful.’ A totally useless message. A workflow log here would have been very useful.

    While digging more, I found the previously posted error message/stack trace in the Deployer machine’s event viewer. (Message: Invalid path: rnrn…).

    My guess is that somehow: Xcopy seems to have a problem with the destination directory.(here in the tutorial:c:WebsitesTailspin.Web). I tried creating the path, setting all the permissions in the world….but nothing.

    All I am trying to achieve is to copy my release from my Release Mangement machine into my remote deployer machine.

    Any ideas? Anyone managed to get this tutorial working all the way?

    Thank you

  4. James Tupper April 1, 2014 at 12:02 pm

    My apologies! I only saw the error with the invalid path. Have you tried running the Xcopy from the command line to see if you can get any other error details? Could you send screenshots of how you have it configured?

  5. James Tupper April 9, 2014 at 12:55 pm

    Thanks, Kenny! Sorry for the late response, we’ve had some issue with approving disqus comments lately 🙁

    Where are you not able to select the team project/build definition? When you’re creating the release template? Have you connected the Release Management to TFS in the earlier step? What exactly are you seeing?

  6. Jamie Graziano April 16, 2014 at 10:29 pm

    Hello, our team has a test Release Mgmt Server setup and we have noticed that our test servers seem to go offline everyday whereas our QA servers are always oline and active. Is there any particular event on a deploymnet agent server that would cause it to go offline? I suspected the Microsoft Deployment Agent service was what provided that status back to the RM client but after stopping that service and still seeing the client report back as “Ready” I wasn’t so sure.

    Thanks in advance for any suggestions…

  7. Martin Hinshelwood April 17, 2014 at 8:22 am

    Jamie, That is not by design and the RM client really does not know anything about your servers and what they are used for. If they go offline at the same time every day I would look to a network issue or some sort of scheduled task that results in the servers looking like they are offline. It takes a little bit of time for the pings to result in ‘offline’ so there may be a delay both ways for a status change.

  8. Stanley April 24, 2014 at 3:09 am

    I have the same problem as Kenny ! TFS Connection was defined and is active but I cannot choose team project or build def. Any idea how to solve this ? Thanks in advance, Stanley.

  9. James Tupper April 24, 2014 at 9:11 am

    Can you give me more detail as to what exactly is going on? Can you screenshot the TFS connection information? Any errors or logs that you can share? Feel free to reach out to me offline:

  10. Stanley April 28, 2014 at 4:47 am

    As you asked I sent you 2 sreenshots from RM for TFS 2013
    (My TFSConnection and Release Templates properties)
    I get no error mesage and no log file,
    I just see empty drop-down lists for selecting Team Project and for Build Definitions
    in Release Template properties window.
    The TFSConnection is to TFS 2012 server.
    As I read, RM for TFS 2013 is compatible with TFS 2010/2012 too.

    The Release Template works – I can trigger it manually.
    But if I want to trigger it from a build I suppose I should
    name it in release Template properties (or am I wrong ?).

  11. James Tupper April 28, 2014 at 8:53 am

    Kenny, Stanley has pointed out that he sees this behavior when connecting to TFS 2012; however, when he connects to TFS 2013 the projects and build definitions appear in the drop down. Are you connecting to TFS 2012, or 2013 when you see this?

  12. Stanley May 5, 2014 at 1:13 am

    Sorry for posting twice the same but the issue is quite important for me – this time in the same thread.

    As you asked I sent 2 sreenshots from RM for TFS 2013 (My TFSConnection and Release Templates properties). I get no error mesage and no log file,
    I just see empty drop-down lists for selecting Team Project and for Build Definitions in Release Template properties window.
    Important info: the TFSConnection is to TFS 2012 server.
    Rel. Management for TFS 2013 is supposed to be compatible with TFS 2010/2012 too. When try communicating with TFS 2013 (different server, different project) I can see builds and proj. collections in drop-down lists.

    The Release Template works – I can trigger it manually. But if I want to trigger it from a build I suppose I should name it in release Template properties (or am I wrong ?).

  13. James Tupper May 5, 2014 at 8:48 am

    Hi Stanley, thanks for pinging me again! I currently don’t have an environment to replicate the issues that you are currently facing (no 2010/2012 servers). That being said, I’ve responded to your email with some screenshots and troubleshooting steps.

  14. ThomasSteiner May 8, 2014 at 12:23 am

    Update: I just found that the Password to the TFS-Server no longer worked…

    When I build my solution I get the following error:
    ERROR: No release template matching the current build definition was found to create a release and deployment for.
    I have a release template (with the same name as the build-process) but somehow cannot set the builddefinition in properties.
    I use version 2RC
    What configuration step is missing?

  15. Stanley May 8, 2014 at 5:05 am

    It’s similar to my case. I’ve never been able to set build definition in properties (empty drop-down lists as above).
    So you previously managed to trigger release from a build and it suddenly stoped to work (build defs unvisible in release template) ?
    I’m using TFS 2012.

  16. James Tupper May 8, 2014 at 8:53 am

    I’ve been seeing more and more topics pop up on the MSDN forums around this particular issue:

    I’ll keep perusing around and let you both know if I can find any answers around this.

  17. DavidV June 17, 2014 at 6:26 am

    We had the exact same problems as you. We fixed it by allowing anonymous access on the Release Management website and ReleaseManagement folder in that website on the server where you installed Release Management Server. I hope this fixes your problem, let us know…

  18. DavidV June 24, 2014 at 7:32 am

    Kenny, (and Stanley)
    Apparently the authentication settings on the website running the Release Management server is responsible for some of the errors we are seeing here. Allowing or disallowing anonymous access on the website running release management fixes the xcopy problem and also the problem of not being able to select a team project/build template. Playing with the anonymous access settings will allow you to fix the problems you are facing. At least, it fixed my problems, sort of :). There is a structural problem using Release Management tool (client and server) that is related to authentication problems. Hopefully this will be fixed in new updates of the tool (I did not check update 3 CTP yet as it was released a couple of days ago), until that time we will have to tweak our way around this 🙂

  19. Stanley July 10, 2014 at 6:57 am

    I found solution month ago, i see proj. collections & builds. Administration -> MyProfile. This Account in MyProfile should be domain profile with access rights to TFS. Thanks for your suggestions.

  20. Stanley July 10, 2014 at 7:27 am

    I found solution month ago, i see all builds. Administration -> MyProfile. This Account in MyProfile should be domain profile with access rights to TFS. Thanks for your suggestions.

    Another question. In ReleaseDefaultTemplate.11.1.xaml template of build triggering a Release in Release Mngmt. There are 2 activities dropping files to drop location (same source & destination).
    I copied these new activities to my TFS 2012 build according to official “User Guide. RM for VStudio 2013”.

    1st: ADDITIONAL “Copy Files To Drop Location” after building binaries and before releasing a build (when ReleaseBuild = True)

    2nd: TRADITIONAL “Drop Files To Drop Location” in “Try Compile, Test, and Associate Changesets and Work Items” -> Finally.

    In log I see two 8-9 min. activities copying the same set of files from the same source to the same drop folder.
    So when (ReleaseBuild = True) – there is aditional 8-9 min. of copying. Why ?

    Is this is a BUG ? I’d rather skip 2nd unnessesary drop.

  21. Stanley July 28, 2014 at 2:08 am

    I’ve just turned off (using “if 0=1”) one redundant drop activity, the one from DefaultTemplate.11.1.xaml, made at the end of build workflow. There’s only 1 left – the new right after building the binaries.

  22. Karthik TS August 18, 2015 at 11:48 am

    Awesome article!! It saved lot of my time..Thank You

  23. James Tupper August 18, 2015 at 12:06 pm

    Thanks, Karthik! Glad it helped 🙂

  24. Nilave September 12, 2015 at 12:02 pm

    What if we are creating a Release Template for Dev stage and it has multiple servers. In your example you have drag&dropped one server. What if i need the same template for multiple servers in a particular stage?

  25. Potte Sira July 8, 2016 at 5:25 pm

    How do you change the .net version from 4.5 to 2.0 using RM?

Leave A Comment