New Windows Service deploy with Custom User doesn't grant log on as a service rights

Legacy Uncategorised
1

Just started using the newer Octopus 2x after using 1.6 for a good amount. Liking the configurations so far! However, I’ve found a problem that I believe Octopus should be able to handle so let me know if I’m wrong. Here’s the situation:

  • First time install of a windows service to a new system (in this case Windows 2012).
  • Service will get deployed to the system ok and set up correctly but the service fails to start.
  • Service is set up to run as a custom user who’s in a group that’s an admin on the box.
  • Logging manually onto the system and trying to start the service shows me that it failed due to login rights. User and password (presumable since it’s masked) were set up correctly.
  • I can now change the password and try to start the service, which windows will now prompt me with a “Do you wish to grant xxxx rights to log on as a service?”.
  • After doing this I’m able to start the service ok. In addition, I can now go back to Octopus and it can deploy and start the service ok.

So should Octopus be setting up that permission itself? Or do I need to handle this in a powershell script? Thanks in advance!

2

Hi,

Thanks for getting in touch! We considered doing this automatically in Tentacle, but I’m a bit worried about having Octopus grant permissions implicitly like this. As you say, using a PowerShell script to ensure the user has the right (or possibly setting it via group policy) would be the way to go. Hope that helps!

Paul

3

Ahh, bummer! Ok, I guess it’s off to Powershell!! It’d be handy to have this documented in the Windows Service section though.

One option that could help your concern would be to have checkbox (default unchecked) that would be displayed when choosing Custom User that would say something along the lines of “Grant logon as a service rights if new user”. Therefore it’s still up to the user to decide whether it’s needed or not.

4

Hi,

This is a great suggestion, thanks!

I’ve added an entry in our UserVoice which you can vote on and comment here:

It’s a feature we would like to implement (like so many other features), so adding your vote will help decisions on future features we implement.

Vanessa

5

This works:

$identity = $OctopusParameters["Octopus.Action.WindowsService.CustomAccountName"]
$nugetExists = Test-Path "$env:TEMP\nuget.exe"
if ($nugetExists -ne $true) {
    Invoke-WebRequest "https://dist.nuget.org/win-x86-commandline/latest/nuget.exe" -OutFile "$env:TEMP\nuget.exe"
}
& $env:TEMP\nuget.exe install Carbon -ExcludeVersion -OutputDirectory $env:TEMP
Import-Module $env:TEMP\Carbon\Carbon
Grant-Privilege -Identity $identity -Privilege SeServiceLogonRight