I am trying to create a process where I have mapped 3 different Virtual Directories on network drives that use custom credentials. When doing this it seems that octopus is trying to validate access to the directories the same was IIS does (using the default application pool identity, which is not the one for the network drive).
So the thing is that when the application is running (if deployed manually) I cannot check access to the virtual directory from IIS, since it uses the default application pool credentials. But the site can access the virtual directory since it is then using the custom credentials.
It seems that Octopus does the same type of check that IIS does and then fails the deployment process event though it would be working when it was up and running. Is there any way around this?
On another note, I am using the Library “IIS Virtual Directory - Create”. If I wanted to use the native Octopus one - from what I can see I then need to specify a deployment package. I do not want to deploy anything to my directory just ensure it is there and have the correct settings. Is this something that is possible to do with the native one?
Thanks for getting in touch! I had a discussion with my team about your question, and what we suspect may be happening in your case comes down to the user that’s running your Tentacle service. During a deployment to IIS, it first runs as your Tentacle user before setting up the app pool with your custom credentials. The Tentacle user by default is LocalSystem, and as you’re deploying to a network drive, LocalSystem may not have adequate permissions to access it. Could you try giving your Tentacle user enough permissions to access the network drive and see if that fixes this?
Regarding your second question, the native IIS step in Octopus requires you to specify a deployment package. Is the
IIS Virtual Directory - Create library step working well for you?
I hope this helps. Don’t hesitate to reach out if you have any further questions or concerns.
for this particular client I cannot change the permissions on the network drive. I have to use a specific account to access it. As I said before it is possible to set this up manually in IIS (although IIS wont let you test it with the “Explore” action since IIS is not using the correct credentials), it works in the actual website though.
So i guess octopus is trying to verify the directory with this functionality or something like it, well when writing I guess it is actually the
IIS Virtual Directory - Create that is trying to verify.
I gather from your answer that there is nothing I can do to tweak the octopus behaviour to work in my case and I have to create my own powershell script?
IIS Virtual Directory - Create is working like a charm.
Thanks for following up! I’m glad to hear that this step is working well for the most part. There’s one potential solution in the case that you can’t change the permissions.
In Octopus 3.7, we added integration with the library and community step templates. This makes it easy to modify the step as you need it. You could in theory find the piece of code that does the permissions check and get rid of it, then save it as a copy and use that. This may be a good workaround to get it working in your environment. You can check out our documentation on community step template integration as well.
Let me know how you go and if you have any further questions going forward.
Thanks for the quick replies! Much appreciated!
I did actually do my own fork of the community step template and added support for checking on addition of network drives with custom credentials. If I have the time to do a more production ready rewrite of the step template I will do a pull request on the repo so that other may share in the joy
That’s not a problem! That would be great, as I’m sure it would be of help to others in the same situation.
Don’t hesitate to reach out if you have any further questions along the way.