IIS AppPool custom user identity does not work properly

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.

I have also tried using: https://library.octopusdeploy.com/#!/step-template/actiontemplate-iis-apppool-create

Same issue.

This is my last hangup in migrating our application deploy processes to Octopus. Please help with this one. Surely there is a solution.

What other details do you need?

Thanks for your help.

Any change a leading space in the password is causing an issue internally for Octopus?

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.

“Set application pool identity: SpecificUser”

Support staff, this paying customer really needs some assistance with the posted issues. :slight_smile:

Thank you.

I post my results back here using an account with no leading space as the first character in the password. Not sure what else to do at this point. :frowning:


Octopus (octopack, UI, etc.) is trimming leading spaces from specified passwords when seting SpecificUser for an AppPool.

Need a bug fix for this ASAP please. This is breaking approximately 50 deploys across numerous servers. Changing the password is not an option.

Thank you!

Posted bug in github.com for you:



Hi Jesse,

Thanks for getting in touch and sorry for the delayed reply. We’ll fix the bug in the next release due today.


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.

In both a variable and the package step directly I have tried:

(first example is a leading space before the “l” character)

" leadingspacepassword"
’ leadingspacepassword’

Hi Jesse,

We’ll try this ourselves, but if you get chance first, here’s another workaround:

  1. Bind the password field to a variable called MyPassword, but don’t actually define it in your Variables page
  2. On your package step, go to Features, then turn on the Custom PowerShell scripts feature
  3. 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. :frowning:

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.

Hi Jesse,

Awesome, thanks for the update! We’ll add something to the next major release to provide a better experience for whitespace trimming in future.



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.

Hi Bjørn,

Thanks for letting us know that the workaround worked for you as well, could you please let us know what version of Octopus you are currently running?

Thank you and warm regards,


I’m running on Octopus Deploy Server version