Adding Handler Mappings to IIS deploy

execution
(bil.simser) #1

Hi guys,

We have a bunch of custom handler mappings we’ve added to IIS to make an application work. Our Octopus deploy just sets the anonymous/authenticated mode on IIS and other bindings but it looks like the deploy is wiping out our additional mappings we added manually.

So a) is this true that it would remove any custom handler mappings we added if something changed say on the website binding? and b) how would we add custom mappings (we have a bunch for .svc files etc.).

Thanks

#3

Hi Bil,

Thanks for getting in touch!

I can confirm that our IIS deployment step will indeed remove any mappings that haven’t been defined in the step itself. This is by design as we consider our step to be the source of truth from a repeatable deployment point of view.

What I would suggest in your scenario (as you have mappings that aren’t set in Octopus) would be to use our Deploy a package step instead. If you enable to custom install directory feature you can deploy your site to the correct IIS folder without disturbing your bindings. I would suggest adding a deployment step so that you can make use of the app offline feature in IIS (otherwise your site may act oddly during a deployment as files are updated).

Please let me know if there is anything else that I can help with,

Regards,
Alex

(bil.simser) #4

Makes sense and I agree the step and whatever configuration is in it should be the source of truth. While I could do it with PowerShell (I think) would be nice if all IIS settings could be setup. Maybe it needs a community step that would do this but I couldn’t find any. I’ll do the deploy package route as that’ll work. I just like the way Octopus deploys to a separate folder then just repoints the IIS site to it. Makes for rolling back easier.

#5

Hi Bil,

Totally understand that the IIS step would be preferable, and yes it is on our list of improvements to make sure we support all IIS options in the step (pretty sure that it’s on our schedule for this year but don’t hold me to that).

Let me know if there is anything else that I can assist with,

Regards,
Alex

(bil.simser) #6

Hey Alex,

Sorry but the deploy is still wiping out our custom handler mappings. I’ve changed the deploy step to deploy a package with the custom install directory feature.

We’re deploying Sitefinity (a MVC based CMS from Telerik) to a folder under wwwroot that we setup manually (along with the mappings and permissions for Sitefinity to that folder for the app pool account to have write permission as it needed it). The only other thing our step does is config transforms.

The custom mappings I added are for Sitefinity to work but after the Octopus deploy the mappings are gone. I confirmed this by:

  1. Manually adding the mappings to IIS and confirming they were there
  2. Running a deploy to the server (see attached log)
  3. Reviewing the IIS mappings only to find them missing

Attached is a (redacted) copy of the Octopus log.

Thanks

octopus-redacted.txt (6.8 KB)

#7

Hi Bil,

That’s very interesting. I’m wondering if something is happening on they Sitefinity side as all the deploy package step is doing is extracting the files included in the package, performing any required config file transformations (e.g. path to SQL database) then copying them to the final destination.

You can see that in the logs,
Extraction:
07:24:45 Verbose | Extracting package to: C:\Octopus\Applications\Development\SitefinityWebApp._APPNAME\1.0.0.21_1
Config Transform:
07:24:50 Info | Transforming 'C:\Octopus\Applications\Development\SitefinityWebApp._APPNAME\1.0.0.21_1\web.config' using 'C:\Octopus\Applications\Development\SitefinityWebApp._APPNAME\1.0.0.21_1\web.Development.config'.
Final copy:
07:24:51 Info | Copying package contents to 'C:\inetpub\wwwroot\APPNAME'

So I’m very curious as to why the mappings have disappeared. As a test are you able to perform functionally the same process manually? You should be able to copy the files from C:\Octopus\Applications\Development\SitefinityWebApp._APPNAME\1.0.0.21_1 to 'C:\inetpub\wwwroot\APPNAME' and see if the mappings are removed as part of that process.

I can’t see anywhere in the logs where we would be interacting with IIS, and that step in particular (deploy a package) definitely won’t. Are you also able to check and make sure that there is nothing in Sitefinity that might be resetting your IIS settings?

Thanks Bil, I look forward to hearing from you,

Regards,
Alex

(bil.simser) #8

Hi Alex,

Turns out that the default web.config file had it’s own set of handlers it was setting in the system.webServer > handler section. I just ended up adding the custom ones to it as part of the deploy. There’s no “clear” statement in this section so it shouldn’t have been removing the manual ones we added but I think those were being saved in the web.config file itself (when you manually add them) so each deploy was using the project web.config file that didn’t have the new mappings. In the end, Octopus was doing what it was meant to and I think the problem was more between the keyboard and chair.

Thanks

#9

Thanks Bil,

Good to know that you managed to get to the bottom of the issue. We’ve all been there with PEBCAK problems :slight_smile:

Let me know if there is anything else that I can help you with,

Regards,
Alex

(system) #10

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