I was just trying to set up a Windows Service deploy running as a Custom user (and password), and got an error that the service couldn’t be started.
When I went to the machine that this was on and tried starting the service again, it failed with "Login failed."
I manually updated the service Login information (updating the password only), hit OK, hit start and the service started.
So I copied and pasted the password back into Octo and ran through the process again and again got the failure. Tried pasting that same password into the login on the service and again the service started.
Did several variations of this, trying variables, trying entering it directly, all with no luck.
Finally tried switching around the password. The two characters that I’ve seen that seem to cause issues in the password are the hashtag (#) and double quote ("). If I updated the password by removing those (in AD and in Octo), the deploy works.
I had the exact issue today. I have a password that ends in # and it fails. I have a template that I’ll soon be contributing to the library to Uninstall a TopShelf and another Install it. The abbreviated code for the install looks like this:
If I run that from PowerShell directly it works fine but in my step template it fails. When I write the command out to the host Octopus drops the # character to a new line:
16:06:52 Info | Using username $username with password $password
16:06:52 Info | Executing: & 'VE.VMF.OfflineMachineMonitor.exe' install -username:MyServiceAcct -password:mypassword123
That issue was closed without an actual fix. I’ve been told that variables with $ have been fixed, but the devs had some issues replicating anything else so the issue was removed from backlog.
So for me to reopen it id have to be able to replicate it. Could you give me a very specific use-case. Id need a password with the exact symbols you are having issues with, where it is defined, where it is called, if its called from a powershell script I would need a copy of that. Pretty much if you can set me up to show it ‘working’, I can then get it reopened and on the list.
We’ve since regenerated all our service passwords to be alphanumeric to avoid this problem, so I can’t give you an actual password, but simply enough, make one that has a # in the middle of it.
What we were trying to do, same as the original poster, was to set the username/password for a windows service to run under. The powershell script to do this is this:
$servicename, $username, and $password were constructed out of variables, resulting in values like:
$servicename = “AOC PLog Queue Service XYZ”
$username = “XYZDemoAppUser”
$password “abcd#1234”
The script would run with no problems, the username/password seemingly set for the service. But the service would not start (a later project step), reporting a problem with the credentials. If we were to then manually enter the password on the server for the windows service, it would be able to start up correctly.
Apologies for not responding sooner, but much like Mike Jacobs, I have long since regenerated the passwords, and I hadn’t planned on replying until I had a chance to validate whether it was fixed. However as I noted in the original note, the two culprits I saw were the pound sign (#) and double quotes (").
I was doing this with a service account like Mike said, but I wasn’t using custom powershell. I was using a variable (sensitive option checked) to fill it in on the deploy step with the Windows Service: Startup configure option checked.
Again I haven’t had a chance to validate, but am responding because the pound sign (#) mentioned by Mike J. was definitely one of the culprits.
I just saw this again last week using 2.6.5.1010. The problem that always comes with this one is that this is ends up being something “easy” to fix in that I adjust the password and move on (and typically is related to something to that needs fixing immediately).
We are using 3.0.23.0 and are experiencing this issue as well. The password in question has a * at the end of it, and regenerating passwords is not a long-term solution with dozens of applications in all environments eventually moving to Octopus for deployments.
Attached is a deployment log for the deployment mentioned by LarzStarz above. The deployment was successful from Octopus’ point of view, the only issue is that the password set for the application pool is incorrect after deployment. Once manually updated to include the ‘*’ sybmol, the application pool runs successfully.
This is version 3.0.23.0 of Octopus Deploy.
