DVLS staging instance as nested application

Hi Daniel,
Sorry for the late reply; this slipped through the cracks.

I don’t see this as a bug. It feels more like an improvement.

In practice, I rarely see nested applications; users typically create a new IIS website. I also find it cleaner to keep production and staging separate.
We could clarify the documentation and recommend creating a new site.

Did you set things up this way because of the documentation, or was it a personal preference?

Best regards,

Thank you!

It was our decision to move it from /dvls to / because it made it easier to use and set up clients. Devolutions support helped us with that. Before we had a HTTP redirect from "dvls.example.com/" to "dvls.example.com/dvls", but the clients (RDM, WS extension) don't follow that.

Best regards,
Daniel

Hi Daniel,

Thank you for the detailed explanation and for sharing your findings.
After reviewing your setup and comparing it with the documented installation model, I want to clarify the situation and close the loop on this case.

The behavior you encountered is expected when a DVLS staging instance is installed as a nested IIS application under a production DVLS instance running at the site root (“/”). In this configuration, IIS applies configuration inheritance from the parent application. Since DVLS defines ASP.NET Core handlers and modules at the application level, the staging instance inherits those settings and attempts to register them again, which results in the duplicate aspNetCore handler error and the related feature delegation warnings.

Your workaround of removing the inherited aspNetCore handler in the staging web.config is technically correct and explains why the staging instance starts successfully afterward. However, this setup is not a recommended or supported deployment model and may require reapplying changes after updates.

The supported and recommended approach is to host the staging instance as a standalone IIS application boundary, typically by using a separate IIS site with a different hostname or port. This avoids IIS configuration inheritance and ensures predictable behavior during installation and upgrades.

Given this, the behavior is not considered a product bug but rather a limitation of the IIS deployment topology. We’ll take this as feedback to improve clarity in documentation around staging deployments.

Thank you again for the thorough investigation and for sharing your observations.

Best regards,
Michel Audi
Support Analyst | Analyste Soutien Technique

Hi Michel!

I installed another update for the staging environment and got the error again. I'll do the same thing as last time to fix it, but I'm not sure about this part:

Unable to configure feature delegation. Please ensure the feature delegation is set to Read/Write for these features:
- Authentication - Windows
- Handler Mappings
- Modules

Does this error result from the problem with the "aspNetCore" handler, or is it something else that we need to address separately?

When we next migrate DVLS to another server, we'll make sure they are not nested sites anymore.

Thank you!

Best regards,
Daniel

Hi Daniel,

Thank you for taking the time to document your findings and for your patience while we reviewed this. We’ve replicated the behavior you encountered and can confirm that it stems from how IIS handles nested applications.
When a staging instance is installed as a child application under a production DVLS site running at the root (“/”), IIS inherits ASP.NET Core handler and module definitions from the parent. During installation or upgrades, the staging instance attempts to register these handlers again, which leads to the “duplicate aspNetCore handler” error you’ve seen. This inheritance also causes the warnings about feature delegation because those features are locked by the parent application.

The workaround you applied removing the inherited aspNetCore handler from the staging instance’s web.config is technically valid and explains why it allowed the site to start. However, this configuration isn’t a supported deployment model, and the change will likely need to be reapplied after each update.
To avoid these problems entirely, we recommend hosting the staging instance as its own IIS site (with its own application pool), using a different hostname or port (for example, staging.dvls.example.com). This isolates configuration and prevents handler duplication. When you next migrate your DVLS installation, creating distinct sites for production and staging will resolve the issue permanently and sidestep the feature delegation warnings altogether.

In the meantime, if you continue using the nested setup, you’ll need to remove the aspNetCore handler after each upgrade and ensure that feature delegation for Authentication → Windows, Handler Mappings, and Modules is set to Read/Write so the installer can configure these features. We’ll also update our documentation to emphasize that nested installations are not supported and to guide customers toward separate sites for staging environments.

Thank you again for your thorough investigation and valuable feedback. Please let us know if you have any further questions or need assistance setting up the staging instance as a separate site.

Best regards,