Configuring Release Management to work across untrusted domains

Configuring Release Management to work across untrusted domains

Rate This
  • Comments 13

There are times when you will want Release Management (RM) to interact with machines that are not part of the same domain. This post details the steps required to configure RM to work across untrusted domains. 

Configuring the Microsoft Deployment Agent

Follow these steps to configure the Release Management Server and the Deployment Agent on machines that run in different domains that do not have a two-way trust relationship.

1.       On each computer where you will install the RM Server or Deployment Agent, create a local user account that is a member of the Administrators group. Use the same account and password on each machine (i.e. Shadow Account).

2.       Add the RM Server’s Shadow Account to RM and grant both “Service User” and “Release Manager” permissions.

3.       Add the Deployment Agent’s Shadow Account to RM and grant “Service User” permission.

4.       Use the Shadow Account as the service account when you install and configure the Deployment Agent.


Note: When you add the local accounts to Release Management, include the name of the local machine where the account resides.

For example, add the user account as <Release Management Server machine name>\<username> or <Deployment Server machine name\<username> 

Configuring the Release Management Client for Visual Studio 2013


In the case where it is your Release Management Client application is running in a different domain than where the Release Management Server is installed, configuring a Windows Credential in the Credential Manager of the client machine will enable the authentication to happen successfully. 


1.       Open the Credential Manager on a client machine.

2.       Click on Add a Windows credential.

3.       Enter the necessary information.



5.       Open the Release Management Client and it will now open correctly.

6.       These steps will need to be repeated for each client machine that needs access to Release Management.

Leave a Comment
  • Please add 3 and 4 and type the answer here:
  • Post
  • Great job Roopesh!

  • The client connection procedure is not working for us. We are not able to connect the client from another domain.

    Release Management Server is on DOMAIN_MAIN and the client connects from DOMAIN_DEV.

    I created a user in Release Management linked to the AD account DOMAIN_MAIN\user.

    On the client, Windows Credentials were added with the url of RM ( and the DOMAIN_MAIN\user and password.

    It seems like the RM client is ignoring Windows Credentials.

  • The steps for the release management client do not work at all.

    The Release Management Server is installed on a server in a domain. While the Release Management Clients are not part of any domain.

    No matter what Credientials are entered it still says:

    "The current user does not have access to Release Management. Please log in with a valid user or communicate with the Release Management administrator to add your user".

  • I've followed the instructions, but the deployment agent configuration fails with:

    System.Net.WebException: The remote server returned an error : (404) Not Found

    when trying to configure the service user (shadow account)...

  • The authentication part of the Release management Client is kind of screwed up. It took us a long time to figure out how to get it working. It works, but not as it should be working. These problems need to be fixed before the tool can be used widely in the field.

    If the machine you are running release management client is joined to a domain and you login to that machine using a domain user, then you simply add that domain user in the administration tab in release management and everything will work as expected. However, if your system is not joined in a domain or you do not login to your PC using a domain user, you will have a very hard time getting Release management client to work. These are the steps to get it working:

    1. Add user mydomain\UserA to release management and give it role "Release manager"

    2. Add user mydomain\UserA to credential manager of the client machine as explained by Roopesh

    3. Now for the really tricky part to get it working: if you login to the client machine using an account different from mydomain\UserA, for example mymachine\UserB, then you need to add "UserB" (no domain or nothing just plain "UserB") to release management and give it the role you want that user to have.

    If you follow this steps, you will be able to get release management client to work. Of course this is just a hack to work around the authentication and authorisation bugs of the Release management server and client, but it will get you going until the tools are fixed to do proper authentication and authorisation. Until that time just be aware the mydomain\UserA has the role of release manager. Without that role the client will not work unless you use shadow accounts which is another way to get the problem solved but a pain to implement since you need the password for mydomain\UserA :(.

    Btw, the deployment agent will not work using this trick, there you will need to use shadow accounts on the release management server.

  • What about the use of a drop folder across untrusted domains. The deployment agent in the dmz domain cannot access the build drop folder in the company internal domain. And my system admin doesn't allow to open the firewall for a network share in the company internal domain. The other way around (so share in the dmz) is no problem. But then I face the problem that the build server has to drop the sources at 4 different locations. Because D, T, A and P all have their own domain.

    Any idea's how to solve that?

  • In the above, under Configuring Deployment Agent, where it says:

    2.       Add the RM Server’s Shadow Account to RM and grant both “Service User” and “Release Manager” permissions.

    3.       Add the Deployment Agent’s Shadow Account to RM and grant “Service User” permission


    A. What is meant by "Add the RM Server’s Shadow Account to RM"?  Is that something one does inside the Release Management UI?  (Sorry I don't have auth to login to the RM Server, so an answer here will help me explain to our Admin what needs to be done.)

    B. Does "Add the Deployment Agent’s Shadow Account to RM" mean add "TargetMachine\ShadowAccount", where TargetMachine is the machine being deployed to that is running the DeploymentAgent?

    Thanks in advance...

  • Hey Bas van Hal,

    Within the RM Client, under the "Server" configuration tab there is a subtab for the deployer agent. Within this tab, you can configure if you want your deployer agent to access your build drop folder from an UNC path or through HTTP. I guess you'll need to use HTTP if your agent is outside your domain.

  • BTW, this article was copied from

  • @Clementino - it is about same product

  • @Roopesh - I think you missed the point about my comment: if this text was published before by another author at another website then the "© 2014 Microsoft Corporation" note at the bottom of the page is not valid, even if it was you who originally created the text while at InCycle and Jonathan Rajotte published it on your behalf before joining Microsoft. My comment was to flag to the MSDN documentation team that they will have to either paraphrase or resolve any IP issues before adding these instructions to the documentation, as they usually do when a blog post becomes a reference.

  • @Roopesh - BTW to make it clear: thank you for re-purposing those instructions and publishing them here. I have been going through everything I can find related to RM, and this page was an important piece of the puzzle. Regards, -Clementino

  • Configuring on a client is not so bad if you can get access to the client UI. Not so easy if your client reports "the current user does not have access to release management".

    However, if you do as above and instead of worrying about the non-domain client concentrate on installing a client on the RM server instead. You can then setup a user from the non-domain client on the RM server client UI.

    Then when you run the client install and add in your URL it connects up fine from the non-domain client.

Page 1 of 1 (13 items)