Configuring vnext to run in a sub-directory

Hi Fred,

To the authentication issue: You might be able to add a second rewrite rule in which you specify conditions like

{HTTP_HOST} matches <sub>\.ctrldocs\.com
{URL} matches vnext#.*

and then rewrite or redirect to the destination required. 
See https://nicolas.guelpa.me/blog/2015/02/21/rewrite-redirect-iis.html and https://learn.microsoft.com/en-us/iis/extensions/url-rewrite-module/url-rewrite-module-configuration-reference 

Good pointer. For the M-Files root site (the classic one in this instance) I added in a redirect rule to always ensure a trailing slash on /vnext like this:

<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Append trailing slash to /vnext" stopProcessing="true">
          <match url="^vnext$" />
          <conditions>
            <add input="{REQUEST_URI}" pattern="/vnext$" />
          </conditions>
          <action type="Redirect" url="/vnext/" redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

Then after authentication, iis redirects the /vnext#code to /vnext/#code and all is well. This does not fix the issue with the new M-Files weblink however, as that page still uses absolute paths to resources, and hence, tries to get scripts and styles from / instead of /vnext.

You might be better off using Vnext as default and placing Classic in a sub folder.

I have added this condition in my configuration to avoid redirect of the Classic sub folder:

{URL} Does Not Match the Pattern (/Classic.*)

The thing is, we need to go slow with this customer and have vnext as an option, so we cannot change the default website. Also we have many links to documents in external systems, and then all those would have to be migrated.

OK.
You can have multiple rewrite rules that handles different types of links and rewrite or redirect them differently. You just need to add conditions in each rule that filters out links that should be handled by another rule. So you can have a general rule that handles common links except those needed for authentication, another rule that handles the authentication links and perhaps a third that handles scripts and styles etc. The difficult part, of course, is to configure the filters correctly to split up those different types of rules.