When using MS Release Management, I found that during a Release, deploying a Powershell/DSC component always takes at least one minute to complete, even if the actual work within that step (copying the files and executing the Powershell script) takes less than a second. This effectively means that with every component that we added to our release template, this increased the duration of the release with another minute.
Especially if you want to minimize application downtime, this seems like an overly long time to wait for nothing.

Logging to the rescue again

So lets see if we can find out why this is happening. MS Release Management consists of several parts, and the one performing the actual Release Management process appears to be the Release Management Monitor, which is run as a Windows Service. It has its own ReleaseManagementMonitor.exe.config file (located in MSRM’s bin folder), and using it, we can turn on logging by replacing the <system.diagnostics> section with the following fragment:

  <system.diagnostics>
    <trace autoflush=&quot;true&quot; indentsize=&quot;4&quot; />
    <sources>
    <source name=&quot;DTLHosterTracing&quot; switchValue=&quot;Information&quot;>
      <listeners>
        <remove name=&quot;Default&quot;/>
        <add name=&quot;DtlListener&quot;/>
      </listeners>
    </source>
    </sources>
    <sharedListeners>
      <add name=&quot;DtlListener&quot;
         type=&quot;System.Diagnostics.TextWriterTraceListener&quot;
         initializeData=&quot;C:LogsReleaseManagementMonitorDtl.log&quot;
         traceOutputOptions=&quot;None&quot;>
        <filter type=&quot;System.Diagnostics.EventTypeFilter&quot; initializeData=&quot;All&quot; />
      </add>
    </sharedListeners>
  </system.diagnostics>

In order to have these settings take effect, the service should be restarted. In Powershell:

Restart-Service "Release Management Monitor"

If you deploy a release with these settings, you’ll find that as soon as the Deploy stage starts a new logfile is created with some very useful information:

Adjusting the Deployment Heartbeat

As you can see, there appears to be a configuration setting called DeploymentHeartbeatValidateIntervalSec that defaults to 30 seconds. During the deployment of a component, this heartbeat period always appears at least twice (see screenshot). Why, I don’t know, but the actual deployment of the component always seems happen on the second heartbeat – this can be seen by the output from “Hello.txt” (see inset), which is what my Component produced.

Knowing this, it’s a pretty safe bet that we can add an appSetting that overrides the duration of this heartbeat. And indeed, if you add the following to the ReleaseManagementMonitor.exe.config file (don’t forget to restart the service)…

  <appSettings>
    <!-- ... -->
    <!-- Determines how often the remote windows service is polled to see if it has finished 
         deploying; defaults to 30 seconds. -->
    <add key=&quot;DeploymentHeartbeatValidateIntervalSec&quot; value=&quot;5&quot; />
  </appSettings>

… you’ll find that each component now only takes a minimum of 10 seconds (plus some overhead because of “real” work) to deploy:

Note that I wouldn’t recommend going lower than 5 seconds (or even 10 seconds), because as you can also tell from the logs, on each heartbeat a new PSRemoting connection is set up, which actually spikes the CPU – and you don’t want to hammer every machine during the deployment.

Adjusting the component deployment interval

With the heartbeat adjusted, you might also notice that every component is being deployed on a 15-second boundary:

Luckily, this interval can be reduced too by using the DeploymentEventFetcherInterval appsetting:

    <!-- Determines the rate at which is checked if the next Component can be deployed (i.e. 
         how fast new rows are added to  the &quot;Deployment Log&quot; window). Default is 15 seconds. -->
    <add key=&quot;DeploymentEventFetcherInterval&quot; value=&quot;5&quot; />

Hope this helps!

Note: A colleague of mine told me that after restarting the Release Management Monitor service, every Release Management client started after that showed the message “This license has expired” and refused to go further, even though they’re using the fully licensed version.

I haven’t experienced this myself, but if this happens to you, recycling the Release Management AppPool in IIS (or simply doing a full “iisreset”) should make MS Release Management recognize again that it’s running the full version.
I don’t believe it’s directly related to the modifications described above but rather some sort of general hiccup that sometimes happens.