Leave a Reply


  1. First of all, thanks for this very helpful blog. It has been rather difficult to find solutions to some of the issues inherent to Release Management. This particular problem has caused a lot of frustration as the Release Template we use consists of 26 components per environment. Each component took at least 1:45 to complete, with some of course taking a bit longer depending on their actual workload.

    Using your suggested solution (setting both DeploymentHeartbeatValidateIntervalSec and DeploymentEventFetcherInterval to 5 seconds), we brought the minimal required time down to approximately 0:55. While this is obviously a vast improvement, we were still a little disappointed after seeing your screenshot of a component taking a mere 0:17 to complete. Would you say this low time is purely because it wasn’t a realistic example and any real world scenario (with for example a Configuration script included) is guaranteed to take much longer? What sort of times are you witnessing with your own actual releases? We’re mainly curious as to whether we should continue our quest for further reduction in release time or give up and accept. Any other tips you might have are welcome as well of course!

    Kind regards,


    Bart l'Amie Reply

    • Hi Bart,

      Nice to hear that this information was helpful to you. Although the 0:17 in the screenshot is taken from a demo setup, a duration of around 20 seconds should definitely be possible if you’re not copying large files or doing too much processing in your script.

      I would recommend creating a simple Release that just copies and runs a simple “Hello world” Powershell script and see how long that takes, to rule out that file size or actual processing time are the delaying factors.
      Next, you could try to remove MSRM from the equation by setting up your own PSRemoting connection from the MSRM server to the target machine – see Secrets of Powershell Remoting for an excellent explanation. if this takes about as long as via MSRM, MSRM is not the problem, but maybe something like resolving host names or setting up the WINRM connection.
      If your own PSRemoting connection does work much faster, it could be that making the connection back from the target to the MSRM machine (to copy the component files from the file share) is what’s causing the delay, so you may also want to try to isolate that part. Just a couple of ideas…

      Léon Bouquiet Reply