Tuesday, July 29, 2014

Connecting release management clients and deployment agents across domains

Microsoft Release Management is a great tool.Where the ALM workflow previously ended with a Build server package, Release Management now brings the tools to move that package to your environments and deploy it automatically.
If you haven’t seen it yet go check it out and give it a try with the Brian Keller VM.
However, running Release Management in a production environment is different from running it installed on one single virtual machine. In this blog I want to share some info I found while trying to install Release Management in more complex environments.

Release Management Architecture

Release Management has a couple of different parts:
  • Release Management Server. This component is installed on your TFS server and is the main part of Release Management.
  • Release Management Client. The client tool is for DevOps what Visual Studio is for developers or Microsoft Test Manager for testers. You run it at your local pc and use it to setup deployments and monitor releases.
  • Deployment Agent. This tool is installed at the servers you are targeting with your deployments. The Deployment Agent uses a pull model where it contacts the Release Management Server at a specified interval to check if there are new releases. This is done over HTTP(S) to avoid firewall problems.

If all components are installed in the same Windows Domain you won’t have any problems. You can add users that can access the Release Management Client and Service Users for the deployment agents to Release Management and you’re all done.
However, when working with multiple domains things can get tricky. Fortunately, Microsoft has some great people working on Release Management who helped me out.

Connecting the Release Management Client from a different domain

The first thing you should always check whenever you have any connection problems is if you can access the Web UI for Release Management at: http://<rm_sever>:<port>/releasemanagement. It’s no problem if this URL gives you an access denied error, just make sure you can reach it.
Now let’s get started with the Release Management client. If you have external customers or internal employees that are not connected to your companies Active Directory Domain, you have two options when connecting a user.

The first option is to use the domain account of the user and add that to Release Management together with the local username:

  • Add the domain account for the user to Release Management as both a Release Manager and a Service User.
  • Add the username that the user is using on his local pc to Release Management as a Service User (and as a Release Manager if the user should be a Release Manager).

So for example, my local pc is running under an account named Wouter and my domain account is WdK1111. This means that I need to add both WdK1111 and Wouter to Release Management. Make sure to add Wouter without any machine name in front of it. Just add it as a plain username. You also don’t have to create a local shadow account named Wouter.

After configuring these two users, the Release Management server knows about your local machine account and about your domain account. Now you need to configure the client to know about both.

On the client machine, the user needs to add his domain account to the Credential Manager for the URL of your Release Management Server (like tfsrm.<yourdomain>.com)


And that’s it. After launching your client it will use the credentials from your credential manager and connect to Release Management with your local, non-domain account.

A second option you have is creating a shadow account on the Release Management machine. This shadow account should have the same username and password as your local pc account. This shadow account can then be added to Release Management and you can give it the appropriate permissions. This option is easier to configure since you don't need to configure the Credential Manager or use the domain account of the user. A problem with this option is that you need the password of the users local account. If that's a problem, you could have the user create a second account on their PC that's solely used for connecting the Release Management client.

Connecting the Release Management Deployment Agent from a different domain

The steps for the deployment agent are similar to those for connecting the client. But instead of using a domain account that’s mapped to a real user, you can create a local account on your TFS machine that can be used as the shadow account for your deployment agent.

  • Create an account on your TFS server. For example: DeploymentAgentXXX with a strong password.
  • Create the same account on your deployment server and make the account a local administrator.
  • Add DeploymentAgentXXX to Release Management as a Service User.
  • On the server where you want to install the deployment agent add the DeploymentAgentXXX account to your Credential Manager. Use the URL for your Release Management Server.
  • Install the agent and use the DeploymentAgentXXX account in the configuration screen.

And that’s it! Now both your Deployment agent and client can connect even when they’re not in the same domain.

What about a proxy?

There was one other situation I ran into. A customer was trying to run the Deployment Agent from behind a proxy. Since the Deployment Agent is initiating the HTTP Request, this is still allowed. However, you can still get the error

Failed to configure Release management service user. Error: The remote server returned an error: (407) Proxy Authentication Required”.


You can fix this error by adding the following snippet to your app.config file located at Program Files (x86)\Microsoft Visual Studio 12.0\Release Management\bin\DeploymentAgent.exe.config:

    <defaultProxy useDefaultCredentials="true" />

And that’s it! When you get the hang of it, it’s quite easy to setup Release Management and configure all the authentication settings.

Comments? Feedback? Any problems with getting Release Management up and running? Please leave a comment!


  1. Hi, I really need your help on this.

    I did all you described below 'Connecting the Release Management Deployment Agent from a different domain'.

    I created an account on the deployment server (in another domain), created a local account on the TFS server,
    added the account on the deployment server to the Credential Manager (underneath the 'Generic Credentials', is this okay????).

    Added the tfs server local account as a service user to Release management server.
    And trying to configure the Deployment Agent on the deployment server.

    But get the error: 'Failed to configure Release Management service user. Error: The requested name is valid, but no data of the requested type was found.

    1. I finaly got it to work:
      - Created a local account DeployAgent on the Deployment Server (domain A)
      - Created a local account DeployAgent on the Release Management Server (domain B)
      - Added a 'Windows Credentials' in the Credential Manager on Deployment Server, using the IP address of the Release Management Server, and user name: DeployAgent.
      - Configured the Deployment Agent on the Deployment Server with Account: DeployAgent (without any domain name or server name before the user name).

    2. Hi Dennis,

      could you please elaborate on what you have done differently from what I described above?



  2. Hi,

    I have a very important question on deployment of project using Release Management tool which should be addressed by us ASAP.

    My Question is whether the deployment of project will be rolled back to its previous version if the final approver rejects the deployment through mail.

    Will the status changes to "Reject" only in RM Client..?

    if the status changes to "Reject" only in RM Client then what is the configuration I have to do in order to rollback to its previous version "AUTOMATICALLY" when the final approver rejects the deployment.

    Please help.



  3. Wouter!
    First thanks for your post!
    If you monitoring this blog a have a few questions hoping you can help me resolve issue that I have.
    Follow your instruction I create accounts on both servers. Release management can see my non-domain server, but all release fail with looks like permission issue on IIS:
    "The Installation command \ "C.....\" failed with the exit code \" -2146232576\".
    Any help with this will be greatly appreciated.

    1. Hi, can you tell me why you think it's an IIS issue? You can enable additional logging by using this blog: http://blogs.msdn.com/b/visualstudioalm/archive/2013/12/13/how-to-enable-detailed-logs-and-collect-traces-from-various-release-management-components.aspx Can you see in the log which command failed?

  4. Do you know if this 'issue' has been resolved in the latest version? I do not have control over either domain so they will most likely always be out of sync. Just curious, Thanks.

    1. I've spoken to the Release Management team and this 'problem' is inherent to how client applications connecting to a web service on IIS work. However, they are working on a better solution. Stay tuned for more info!

  5. Thanks for this blog, it give me some of the last peaces I was missing to finally achieve a full setup: how to connect client from an other domain.
    I had to tackle many other troubles before that last one. (Using RM for VS2013 update 2.) Here they are.

    I find out that it can be quite hard to connect to release management over https if you need to do it with a custom fqdn, I mean, one not using the release management server machine name.
    It seems release management site does query itself with remote client credentials, which fails (401) if its hostname is not "well known" by ntlm (aka localhost or machine name).
    Applying workaround of https://support.microsoft.com/en-us/kb/896861 allowed me to overcome this issue.
    But I have no ideas of why this trouble pop-up only when using https, not when using http.
    Detailed step of workaround, to be applied on release management server :
    1 - create/update a registry key named DisableStrictNameChecking of type DWORD with value 1 under HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters
    2 - create/update a registry key named BackConnectionHostNames of type MULTI_SZ including your custom fqdn for your server, under HKLM\System\CurrentControlSet\Control\Lsa\MSV1_0
    3 - reboot your server

    This does not solve an issue with the rm server configuration tool, which does not allow to setup a custom hostname. You may edit it directly in many configuration files as described in https://support.microsoft.com/en-us/kb/2905743, but I ended up with another solution for overcoming an other trouble (read on).

    An other issue was supporting at the same time http and https for accessing the release management server. When you already have lots of deployers running on many target servers, with some on which you have no access, you do not want to break automated releases for some time by switching to https without supporting http anymore.
    For this reason, rather than reconfiguring rm server for using https, I added a reverse proxy site to the release management server IIS, bound to my custom fqdn other https, and using URL Rewrite reverse proxy rule (require ARR) to terminate the https and proxify the rm site accessed over http from that reverse proxy site.

    Quite a complex arch overall, but I have not find simpler to achieve desired outcome.