Password issue not fixed for us in 3.2.6

From Nov.24th posting.

“Hi - This was fixed in 3.2.6 shortly after 3.2.5 was released with that bug. Please upgrade to get the fix.
Sorry for the inconveniences,
Dalmiro”

We are on 3.2.6 and are having the issue that services can not start until we manually reset the password to the same value that Octopus used to install them. When we do a redeploy then the correct password is used.

Hi Glen,

Thanks for getting in touch. I would like to understand the flow of events better, is this what you’re experiencing?

  1. Deploy a brand-new windows service with Octopus - it fails to start
  2. Manually update the password - it starts OK
    a) When you set the password, were you told that the user was granted Log On As A Service rights?
  3. Deploy a new version of the existing windows service with Octopus (where you have corrected the password) - it starts OK

Does that sound about right?

We have confirmed the fix that was applied in 3.2.6 with a much deeper set of automated end-to-end tests, and the customers that were originally reporting issues no longer experience this problem. I wonder if it’s something slightly different we should investigate further, like an encoding issue?

Some diagnostics you could try:

  • Try a different password (to eliminate special character encodings)
  • Try a different user account that is pre-configured with the Log on as a Service right in the Local Security Policy (or Group Policy) for your server.
  • Try updating to 3.2.13 and see if the problem goes away?

Hope that helps!
Mike

We updated to 3.2.13, are using a very simple password and tried a different user ID. This is a Windows 2012 R2 machine, would that cause any issues? We may have something set up wrong in this environment.

Hi Glen,

Thanks for getting back to me and trying out those simple diagnostics. Windows Server 2012 R2 is perfect and offers the best support, so that should not be an issue.

The next logical step would be to set up a support call and get straight to the source of the problem. Could you use calendly to select a time that suits? https://calendly.com/octopusdeploy/supportcall

Hope that helps!
Mike

Hi Glen and Mark,

I’ve created this GitHub Issue to further investigate the behaviour we saw on our support call last week.

I also mentioned I’d send through some reading on Channels and Multi-tenant deployments.

Hope that helps!
Mike