The problem is that Octopus doesn’t seem to support this option and as soon as we choose the “Custom user…” option for “Service Account” it calls "sc.exe with a /password= "**********"
Is there a way to force Octopus to not use a password, even when using Custom Account? If not, could you please add it?
Thanks for reaching out. I’m sorry to hear you are being bugged by this issue. We already have a github issue submitted for this which you can track here: https://github.com/OctopusDeploy/Issues/issues/2264
I’m gonna mention this one to the team and see if there’s any chance to speed up the fix, or at least know what’s blocking it.
The issue you link to is part of the problem but fixing it wouldn’t solve our issue. There is also https://github.com/OctopusDeploy/Issues/issues/2311 and others mentioned which are relevant, but none of them seems to be asking for the possiblity to configure a Custom User with no password, i.e. the call to sc.exe should contain no /password= which as I said, is required when using Group Managed Service Accounts.
I hope you can put a quick fix in or provide a workaround because it’s blocking us badly at the moment.
So yeah in the current state you cannot define a user without a password in Octopus. I even asked the team if we got this question about this scenario before, and you seem the be the first one.
You seem to be familiar with sc.exe, so my recomendation would be for you to change the deployment logic a bit and do something like this:
Use your own Sc.exe command to create the service. You can add this code on the Nuget Package step, have a dedicated Powershell step for it or even create a step template so you can re-use the step any time you want. More info about running scripts: http://docs.octopusdeploy.com/display/OD/Custom+scripts
I’ll try to apply your workaround, but will you consider adding this option to Octopus?
We have a micro-services architecture, i.e. we develop and deploy a lot of indepent services, and we would like to avoid having to maintain custom deployment scripts for each of the services when Octopus already takes care of that.
We actually made some design decisions in order to keep deployments in Octopus as simple as using the “Windows Service” feature and it would be a great disappointment if it turned out we can’t use it after all.
Could you add this as a suggestion in our Uservoice site? The next time we hear from a user asking the same as you, we’ll point them to that sugestion so they can leave some votes on it. If we notice that enough people are looking forward to this, we’ll see to do something about it.
Of the approaches mentioned above, the one I’d recommend you the most is creating a step template based on sc.exe. Not only you’ll be able to re-use it ver easily, but you could also send it on a PR to our Library project on Github so the whole community can download it from our library
Yet another approach would be to make your own calamari build and tweak the sc.exe command on it. You won’t be able to add an option to the dropdown list on the web UI, but you could make it watch for a flag Octopus variable and based on it run the sc.exe command without the password. This is the file you should be looking to modify:
Thanks, I’ll give the template approach a go as soon as I can. For now we discovered that if the service exist (even if it’s just a shell, i.e. no binPath, etc) and is configured to run with the user then Octopus’ se.exe config call succeeds. So we’ve have added a Pre- script that checks if the service exists and if it doesn’t it creates it with the user we want, no password.