Updating templated steps breaks windows services


Im trying to configure octopus for our windows services and think I encountered a bug.
Version 2020.3.6 on Windows-64bit.

Steps to reproduce:

  1. Create a step template based on windows service
  2. Create a deployment process step and use the template
  3. Run the deployment (Works as expected)
  4. Change something in the template
  5. Click the “Update process step” that appears
  6. Run the deployment (Deployment fails because files are in use)

Looking at the deployment log it seems like the Stop/Start service is missing, which in turn fails the file-copy.

I compared the Json config before and after the template update and noticed that this entry was missing after the update:
“Octopus.Action.WindowsService.CreateOrUpdateService”: “True”,

Regards Erik

Hi Erik,

Thank you for contacting Octopus Support.

Would you mind sharing a sample copy of your template so that I may attempt to reproduce this issue in a test environment?

I look forward to hearing from you.


Sure here is what I got from using “Export” on the template:

“Id”: “4b66f8c6-a264-465f-b145-13012969c239”,
“Name”: “Microservice”,
“Description”: “Template for microservices”,
“ActionType”: “Octopus.WindowsService”,
“Version”: 1,
“CommunityActionTemplateId”: null,
“Packages”: [
“PackageId”: “#{servicename}”,
“FeedId”: “feeds-builtin”,
“AcquisitionLocation”: “Server”,
“Properties”: {
“SelectionMode”: “immediate”
“Id”: “fc8f09db-96dd-4366-a9d0-627899362d24”,
“Name”: “”
“Properties”: {
“Octopus.Action.EnabledFeatures”: “Octopus.Features.WindowsService,Octopus.Features.CustomDirectory,Octopus.Features.JsonConfigurationVariables,Octopus.Features.ConfigurationVariables,Octopus.Features.SubstituteInFiles”,
“Octopus.Action.WindowsService.StartMode”: “delayed-auto”,
“Octopus.Action.WindowsService.ServiceAccount”: “LocalSystem”,
“Octopus.Action.WindowsService.ExecutablePath”: “#{servicename}.exe”,
“Octopus.Action.Package.CustomInstallationDirectory”: “D:\microservices\#{servicename}”,
“Octopus.Action.WindowsService.ServiceName”: “#{servicename}”,
“Octopus.Action.WindowsService.DisplayName”: “#{servicename}”,
“Octopus.Action.WindowsService.Description”: “SA microservice”,
“Octopus.Action.Package.PackageId”: “#{servicename}”,
“Octopus.Action.Package.FeedId”: “feeds-builtin”,
“Octopus.Action.Package.DownloadOnTentacle”: “False”,
“Octopus.Action.WindowsService.DesiredStatus”: “Started”,
“Octopus.Action.Package.CustomInstallationDirectoryShouldBePurgedBeforeDeployment”: “True”,
“Octopus.Action.Package.JsonConfigurationVariablesEnabled”: “True”,
“Octopus.Action.SubstituteInFiles.Enabled”: “True”,
“Octopus.Action.Package.AutomaticallyUpdateAppSettingsAndConnectionStrings”: “True”,
“Octopus.Action.Package.JsonConfigurationVariablesTargets”: “appsettings.json”
“Parameters”: [
“Id”: “30f9a66d-c8f9-438f-9bb7-bf1d4e3b5cad”,
“Name”: “servicename”,
“Label”: “Microservice name”,
“HelpText”: “The name, must be the same as the .exe file, ex. Kansli.Billmate”,
“DefaultValue”: “”,
“DisplaySettings”: {
“Octopus.ControlType”: “SingleLineText”
“$Meta”: {
“ExportedAt”: “2020-09-30T14:58:07.608Z”,
“OctopusVersion”: “2020.3.6”,
“Type”: “ActionTemplate”
“LastModifiedBy”: “Your GitHub Username”,
“Category”: “other”

Hi @erik1,

Thank you for providing that.

I’ll try to get this replicated in my test environment and let you know what I find.

Thank you for your patience while I investigate.


Hi @erik1,

Thank you for your patience.

I was able to reproduce the issue in my test environment. I can confirm I am seeing the same problem in that the step template is assuming the service either does not yet exist or is already stopped. I will need to confirm with our engineering team as to whether this is intended behavior or not.

Meanwhile, we have a simple step template to work around this called “Windows Service - Stop”. It is just a simple Powershell script. There is one parameter that requires the exact “Service name” as noted in the properties of the service. There is a “Windows Service - Start” step template as well.


I’ll touch base once I hear back from our engineering team. Let me know if this looks like it will work for you.


Ok thanks.

The powershell template workaround is good for now.

Regards Erik

Hi @erik1,

Thank you for getting back to me.

I have confirmed with our engineering team that this is a bug. If you wish, wu may follow along with the github issue here:

If you have any additional questions about this or anything else, please let me know.


This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.