How to edit registered Release Management deployment agent IP addresses if a VMs IP address changes

I have posted in the past that we have a number of agent based deployments using Release Management 2013.4 that point to network isolated Lab Management environments. Over Christmas we did some maintenance on our underlying Hyper-V servers, so everything got fully stopped and restarted. When the network isolated environment were restarted their DHCP assigned IP addresses on our company domain all changed (maybe we should have had longer DHCP lease times set?)

Worst of all some were reused and were actually swapped between environments, so an IP address that used to connect to a Server1 in environment Lab1 could be assigned to Server2 in environment Lab2. So basically all our deployments failed, usually because there server could not connect to the agent, but sometimes because the wrong VM responded.

Now for general Lab Management operations this was not an issue; inside the environment nothing had changed, the network range was still 192.168.23.x and externally SCVMM, MTM and the Test Controllers all knew what is going on and sorted themselves out. The problem was the Release Management deployment agent’s registration with the Release Management server. As I detailed in my previous post you have manually register the agents using shadow accounts. This means they are registered with their IP address at the time of registration, it does not change if the VMs IP address is reassigned with DHCP. It is up to you to fix it.

But how?

And that is the problem, there is no way to edit the IP addresses of the registered server’s deployment agents inside the Release Management admin tool. The only option I could find would be deleted the registered server and re-add them, but this requires them to be removed from any release pipelines. Something I did not want to do, to much work when I just wanted to fix an IP address.

The solution I found was to edit the IPAddress column in the underlying Server table in the ReleaseManagement DB. I did this with SQL Management Studio, nothing special. The only thing to note is that you cannot have duplicate IP addresses, so they had to be edited in an order to avoid duplication, using a temporary IP address during the edit process as I shuffled addresses around.

Once this was done everything leapt into life. I did not even need to restart the Release Management Server, just press the refresh button on the Server tab and saw all the agents had reconnected.

So a good dirty fix, but something I would have hoped would have been easier if the tools provided a means to edit the IP addresses

Note: This problem is specific to agent based deployment in Release Management. If you are using vNext DSC based deployment to network isolated VMs are registered using their DNS names on the corporate LAN e.g. VSLM-1344-e7858e28-77cf-4163-b6ba-1df2e91bfcab.lab.blackmarble.co.uk so the problem does not occur