Unable to deploy IIS application with domain user

Octopus Server
1

Hi all,

I have a problem which is keeping me awake these days. So we recently built a pipeline for deployment with Octopus. In order to do things right we figured that for the tentacle we would like to have separate, domain managed service accounts. We created this account, added it to the local Administrators group and granted it the Login as a service permission as it’s recommended in the Octopus docs. Here’s the “but”. But when we switched the service to the new user we ended up with the error in the attached log:

InvalidArgument: A parameter cannot be found that matches parameter name ‘physicalPath’.

If we get the user back to Local System - all works like a charm, but with the domain user it fails with this bizarre error. I’m saying bizarre, because I still can’t find a good explanation for this. I’ve isolated the part of the script that is failing, populated the system variables and when I run it from the Script Console - it works. So it seems that when I change the user to the domain one some of the variables are, maybe, not populated correctly? I really have no clue. Any ideas where to start diagnosing this would be much appreciated.

ServerTasks-3289.log.txt (30.0 KB)

2

Hi Alex

Welcome to Octopus Deploy and thanks for posting the task log.

Can I make an assumption that this is the page you followed when creating the login account assigned to the Tentacle service:

At a quick glance through the task log file, it does appear that there might be an issue which is being fixed currently by our Developers where the physicalPath is being lost in the deploy steps:
https://github.com/OctopusDeploy/Issues/issues/6860

However while it appears quite similar I’m not sure it is 100%.

An upcoming release has the above issue fixed and I would check the downloads page to confirm when it is available for upgrade.
In the meantime there is a workaround which may solve your issue, which is to run a post-deploy script.
Here are the details from a previous issue:

In the meantime, a workaround you can utilise is you can Configure Features on that step and add Custom Deployment Scripts and add this as a post-deployment script:

Import-Module WebAdministration
Set-ItemProperty IIS:\Sites\#{VariableForIISPath} `
                   -name physicalPath `
                   -value $fullpath

VariableForIISPath would be the site name with any virtual directories, and $fullpath will be the location on the hard drive where the files reside after deployment.

If you use the default values and not a custom install directory you could build the fullpath by combining system variables like below.

 $path = "#{Octopus.Tentacle.Agent.ApplicationDirectoryPath}"$environment = "#{Octopus.Environment.Name}"
    $name = "#{Octopus.Action.Package.PackageId}"
    $version = "#{Octopus.Action.Package.PackageVersion}"
    $fullpath = "$($path)\$($environment)\$($name)\$($version)"

Please test this in a test environment before attempting it in prod.

Let us know if this resolves the issue or if not we would like to see the Verbose version of the task log to check all the variables. To provide this can you follow the details in this link and post the logs?

Kind Regards,
Paraic

4

Hi Paraic,

Many thanks for the quick response.

You’re right in the assumption. Domain user is local admin, tested also with specifically adding the user to all the folders and the registry entry.

Maybe it’s a different issue, because setting the variable doesn’t change anything. I’ve done some more digging and noticed something funny which maybe is normal but just to check. The deployment always fails on line 362 which in my case is the statement after

"$virtualPath" does not exist. Creating Web Application pointing to $fullPathToLastVirtualPathSegment …

Even if I add the application it still fails on this line, meaning that it’s unable to get the $lastSegment. I initially assumed this is because every time the deployment generates a new path and it won’t find an application with that path so it will try and create it over the old one, but I don’t see the code there taking into consideration the physical path.

Kinda feels like WebAdministration module is missing, but when I do Get-Module - it’s there.

I’m reproducing this on multiple 2019 Windows Servers if it matters.

All the best,
Alex

5

Found the cause of the problem. The root of the parent of the application is pointing to a domain share. As soon as I changed this to local path the error was gone. Still not sure why this a problem tho. The domain user running the tentacle is in a group with full access to that share. Any ideas why this is causing trouble?

6

Hi Alex
Well done on finding the root of the issue.

From a quick look on the Interwebs, IIS can have issues when the identities used for Application Pool are not the same as other settings. Can you do a quick check to see if the Application Pool is running under your Domain account?

Kind Regards,
Paraic

7

Hey Paraic,

The website and all the application under it are running on separate app pools, using the same domain user. This domain user is different from the deployment domain user. Just for the play of it I tried switching them all to the same user and with deploy and app pools running under the same user the issue still exists if the website is pointing to a network location.

As a workaround I’ve got 2 options:

  1. Move the physical path of the website locally, or
  2. Create a pre-deployment script to change the physical path to a local one and then a post-deployment one to get it back. This one is not really ideal as the downtime would be longer.

The really confusing thing is that this is running well if the tentacle is operating under Local System account, because this account has no access to this share…

Would love to know the actual reason behind this problem, but I’m happy that we have a workaround for now.

8

Hi Alex
Good to hear you have a usable workaround.
I will chase this up with our Devs to see if we can get to the bottom of this behaviour and if its an issue in Octopus, we can take it further.

I’ll keep you posted on our progress.

Kind Regards
Paraic

9

Many thanks for the assistance Paraic!

Have a great weekend,
Alex

10

Hi Alex
Just a quick followup on this one.
If you are feeling adventurous the code where the script is failing is here: Calamari/Octopus.Features.IISWebSite_BeforePostDeploy.ps1 at 6ed3be7de2160437d3e833952010c8825e77e7ba · OctopusDeploy/Calamari · GitHub

  • specifically at line 304 and a few lines above for setting the vars.

$fullPathToLastVirtualPathSegment = Get-FullPath -root $sitePath -segments $virtualPathSegments
$lastSegment = Get-Item $fullPathToLastVirtualPathSegment -ErrorAction SilentlyContinue

if (!$lastSegment) {
	Write-Host "`"$virtualPath`" does not exist. Creating Virtual Directory pointing to $fullPathToLastVirtualPathSegment ..."
	Execute-WithRetry { 
		New-Item $fullPathToLastVirtualPathSegment -type VirtualDirectory -physicalPath $physicalPath
	}

Maybe you can try running this as the domain user to see if it pops up anything obvious.

Kind Regards,
Paraic

11

Hey, already did that :slight_smile: I’ve isolated the part that is being executed and the result is the following script:

FailingODScript.ps1 (10.6 KB)

This thing fails with the same error in local PowerShell ISE. Still couldn’t find why exactly, but my PowerShell skills are rather basic.

12

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.