I am having trouble getting the specified IIS Application Pool Identity to work when using Octopus.
I am choosing “Custom User” and setting username / password. The user is applied, but the application pool will fail to a 503 when being accessed. It appears the password is possibly not being applied properly. If I manually reset the password to exactly what I told Octopus to use, site works fine.
The Octopus UI trims the leading space when assigning to an Octopus variable. Maybe this is also the issue for IIS AppPool identity password automation.
How do I work around this without having to change my password?
I have tried setting up a variable using double quotes to contain the leading space. Again, the AppPool crashes with 503 until I manually reset the domian user password.
Octopus deploy indicates it has set the user, which it has been, but the password is not being applied correctly.
Hi Jesse, just to confirm, are you entering the password field directly into the password box on the package step page, or are you binding it to a variable that contains the password?
I have tried both ways and neither works. I have tried binding a variable with the value enclosed in single and double quotes and without adding the leading space. Same result as typing the password directly in the package step UI including the leading space.
We’ll try this ourselves, but if you get chance first, here’s another workaround:
Bind the password field to a variable called MyPassword, but don’t actually define it in your Variables page
On your package step, go to Features, then turn on the Custom PowerShell scripts feature
In the PreDeploy script, call Set-OctopusVariable -Name "MyPassword" -Value " password-wth-space"
This should work around the trimming in the UI. To keep it secure, you could store the password as a variable without the space, then add the space back using the PreDeploy script.
As I said, we’ll try this ourselves and will report back. We’re worried that by not trimming leading whitespace we’ll open up a bunch of other bug reports (people who copy and paste values from emails, for example), so we might look for a more long-term solution if we fix this in the product. That’s why it would be great to find a workaround.
Paul, thank you. I will be trying this today and will let you know.
Even if you could optionally allow indicating to trim or not trim password fields on a per-step basis, that may be a nice feature. Unfortunately, changing the password is not really a viable option for us, so hoping this workaround does the trick. Too many years of messy AD service accounts to worry about.
Paul, this works like a champ! I am now seeing if I can roll the small script into a script module and call it that way so I don’t have to repeat the same thing 50 times.
Thanks and I’ll report back again concerning using the script module in the PreDeploy step.
Paul, all is well. Calling this via a script module in PreDeploy works awesome. Thank you for the workaround. I do not believe I would have ever come up with that solution. Again, thank you.
I’m experiencing the exact same problem with a password that doesn’t contain spaces. Is seems like a “normal” password with just letters and numbers (both upper and lower case). Using the workaround described in this post fixed the problem though.
