Introduction

This is the first in a series of posts I’ll be doing about installing Release Management and using it to deploy a web application using Powershell DSC (Desired State Configuration).

Even though since Update 3 Release Management supports an agent-less model that pushes DSC .mof files, in this post I’m going to use the RM Deployment Agent because I want the deployment packages to be pulled in by the target server – this way, I don’t have to punch holes in the target server’s firewall. (Incidentally, DSC also supports a pull mode, but this isn’t supported by RM out-of-the-box, at least at the time of writing this.)

This post will cover setting up a working RM environment. In part it is based on this blog post by the Microsoft ALM team, but I’ve expanded on it quite a bit so that it serves more as a step-by-step installation guide while avoiding some of the pitfalls one might encounter.

Our machines

The environment we’ll be installing RM on consists of 2 machines, a Release Management server and a target server to deploy to. We’ll assume that these machines can reach each other but are not domain joined, so that we can also deploy to a test or acceptance environment in a different domain.

Note that I won’t be covering how to connect RM to TFS – we’re going to assume that we’ve already obtained the files that we want to deploy through some other means. If you want to use RM in combination with TFS, you can read about it here.

We’ll assume we have the following machines at our disposal:

RMServer
– Windows Server 2012
– IIS 7.5
– SQL Server 2008 or higher (for the RM database)

TargetServer
– Windows Server 2008 R2

During the course of this post, we’ll be deploying the Release Management components on these servers as follows:

Installing Release Management Server and Client

On the RMServer, mount the “Release Management for Visual Studio 2013 with update 4” installation ISO, and run the installation executable from the Server folder. Once the installation is complete, the server needs to be configured. The server needs to run under a local Windows admin account, I recommend creating a separate user for this:

Next, from the same ISO, install the RM client on the RMServer as well – this is for simplicity’s sake, you could use a different server if you wanted to.
Once the installer has completed, start the “Release Management Client” and enter “RMServer” as the location where the server can be reached:

At this point, we have a running RM Server with an RM client that is configured to connect to it.

Adding the Service Users to RM

In order to let the RM Deployment Agent connect to our RM server, we’ll add the user under which the agent will run to our RM server. However, since the RMServer and the TargetServer are not joined by a domain, we’ll have to use a shadow account – that is, a Windows user on the RMServer with the exact same name and password as a corresponding user on the TargetServer. For purposes of cross-machine authentication, Windows will then treat these two users as the same.

So on the RMServer, create a Windows user named “DeploymentAdmin”. It doesn’t need to be a local admin here (but its corresponding user on the TargetServer will be).

Here comes the weird part: we have to add both incarnations of the DeploymentAdmin as separate users to RM. To tell them apart, I have given them distinguishable names. Note that both users need to be marked as a Service User, but only the local DeploymentAdmin needs to be marked as Release Manager – see the screenshots below.

It’s really important that both RM users are added – if you don’t have the TargetServerDeploymentAdmin added, configuring the Deployment Agent will fail with a “(401) Unauthorized“, if you don’t have the RMServerDeploymentAdmin, the Deployment Agent will install, but it will fail to connect to the RM Server with a “(403) Forbidden“. Yes, I’ve tried 🙂

Installing the RM Deployment Agent

In order to be able to perform its deployment tasks on the TargetServer, the Deployment Agent is required to run under a local administrator account.

For this, on the TargetServer, create a Windows user named “DeploymentAdmin” with the same password as the DeploymentAdmin on the RMServer, and add it to the local Administrators group.

Important: When running the Deployment Agent installer, it must be executed under this DeploymentAdmin account, otherwise Agent installation step will succeed but the configuration step will fail because it cannot connect to the RM webservice and will generate a 401 – Unauthorized error.

So, perform the installation by locating the .exe in the installation ISO’s Deployment folder, and while holding Shift, right-click the .exe, choose “Run as different user”, and enter the DeploymentAdmin credentials.

Once the installation is complete, specify the DeploymentAdmin credentials as the account to run the agent under, and specify the RMServer port 1000 as the server it should poll for work:

If you’ve set up the shadow account and RM Service User correctly, the configuration should complete without any errors.

Automatic Delayed start

In order to have these configuration changes picked up, use the Services manager (services.msc) to restart the Microsoft Deployment Agent service.

Incidentally, I noticed that sometimes, after a reboot of the TargetServer, the Deployment Agent wouldn’t pick up any of the releases that get sent to it – the Deployment Agent logs just keep saying “Deployment: No component ready for deployment”.
In this case, restarting the Deployment Agent Service helps, but I also found that changing the service’s startup type to “Automatic (Delayed start)” prevents this situation from occurring. I’m not sure why, but so far this has worked for me.

Adding the TargetServer to RM

With the Deployment Agent running happily on the TargetServer, we still need to tell RM that it can use this server to send release packages to. Note that I will leave configuring the Stage and Technology picklists and adding Environments for my next post – for now, I’ll just focus on adding the TargetServer itself.

In the RM client, under “Configure Paths”, “Servers”, choose to add a “New Agent-based” server, and add the TargetServer as depicted below. Note that we want the Drop Location Access to be “Through Release Management Server over HTTP(S)”, so that the release packages that this server gets sent are transferred over the RM Server’s webservice – this way, the TargetServer (which we consider to be in an isolated test environment) doesn’t need access to a central file share:

In the Servers overview, the TargetServer will initially show up as not having reported a heartbeat yet, but within a minute this status should change to “Ready”:

With this setup, we’re ready to define a release path and start deploying applications – I’ll be covering this in my next posts.