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)

image

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”.

clip_image002

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:

<system.net>
    <defaultProxy useDefaultCredentials="true" />
</system.net>


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!

3 comments:

  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.

    ReplyDelete
    Replies
    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).

      Delete
    2. Hi Dennis,

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

      Thanks!

      Wouter

      Delete