M-Files Web clients installed in a virtual directory

Overview

To install both M-Files Web clients (Classic Web and the new Web client also referred to as vNext) into a virtual directory under your IIS web site, instead of installing them into the web site's root, there are some considerations and common pitfalls to consider.

Here is the list of things to consider and review, each has a dedicated section below:

• Creating the Web Site
• Site Binding Address Value
• Common Classic Web setup issues
• URLs for Accessing M-Files Web
• Links Page does not work after 23.3
• REST API routing issues

Creating the Web Site

Most use cases that require the M-Files Web to be set up in a virtual directory instead of directly as its own web site will have the parent web site already created and hosting some application. In those cases, there is nothing else to do.

In situations when you also need to create a new web site, make sure to NOT point it to the "MFWA" folder in the M-Files Server installation. IIS will require that you define a path for your web site, so you should either choose something like the built-in "wwwroot" folder it has, or you should make a new folder on the server disk with a blank "index.html" file in it and use that. You can edit that HTML file to, for example, hold a link to the actual M-Files Web path in case someone does open the root site.

Site Binding Address Value

The "Site binding address" field in the M-Files wizard must contain the virtual directory name as well, not just the IIS address and port.

For example, if your IIS server has a binding for the parent web site that uses the HTTP protocol, the IP address 123.123.123.123 and port 8080, with the virtual directory that hosts the M-Files Web Access called "myMfilesVirtualDirectory", the site binding address value must be as follows:

http://123.123.123.123:8080/myMfilesVirtualDirectory

Common Classic Web setup issues

See this article for more details: Setting up both Classic Web and Web clients breaks Classic Web.

URLs for Accessing M-Files Web

When accessing the Classic Web, the ending slash is required. For example, if the Classic Web is the default client:

https://myvault.company.com/mfilesVD/

You can also add the default page like this:

https://myvault.company.com/mfilesVD/default.aspx

To access the Web client in this case, add "vnext" at the end, for example:

https://myvault.company.com/mfilesVD/vnext

If you are using Federated Authentication (OAuth), the RedirectURI that has the base URL above must also have a trailing slash - this is the URL that the identity provider redirects the user to, so it must be able to reach the M-Files client correctly.
 

Links Page does not work after 23.3

You may hit this issue when setting up in a virtual directory, even when using the M-Files Admin wizard correctly: /article/Links-page-from-Copy-Link-feature-does-not-work-after-23-3-update. This is under investigation with ID 167218 and 167211, either will be present in the release notes when/if the M-Files Server is improved.

Potential workarounds:

• Avoid using a virtual directory, if possible.
  • This may break existing URLs if the system had already been in use with the virtual directory for some time.
• Remove the Web Url from the Vault Properties dialog.
  • This will disable the usage of the Copy Link feature altogether and Web links will not be generated by the old Get Hyperlink feature and for notification emails. Note that at some point the old Get Hyperlink feature may become obsolete.

REST API routing issues

NOTE: After you set up the web clients, test whether these features work well for you. If they are fine, do NOT perform the following configuration change.

In a few rare cases, the REST API requests (e.g., uploading files, downloading files, both via the API or the Classic Web client, loading a preview in the Classic Web client) have been routed incorrectly. 

To solve such an issue, you need to add your virtual folder path to the Conditions of the URL Rewrite rule that decides which Web client to pass connections to. This is due to the configuration wizard not being aware of the chosen virtual folder path when making REST calls.

NOTE 2: This workaround must be re-applied every time M-Files server is updated. The update will reset the URL Rewrite condition to its default value, so you need to enter your virtual folder path into the URL Rewrite condition again.

To add the virtual directory path to the URL Rewrite rule's conditions:

1. Open IIS Manager.
2. Access the virtual directory in which the M-Files Web clients are installed.
3. Double click URL Rewrite in the middle pane of IIS Manager.
4. In the list of URL Rewrite rules, double click ReverseProxyInboundRule_vNext to access the rule's properties.
5. In the Conditions section of the rule, add your virtual directory path to the {REQUEST_URI} rule just before the word rest. Separate all folders in the path (rest included) with a forward slash. For example, if the M-Files Web clients are installed in a virtual folder called "mfiles", the condition pattern needs to be changed from:
   "^/(?!rpc/|rpcwithcert/|rest/|m/|webhook/).*$" 
   to:
   "^/(?!rpc/|rpcwithcert/|mfiles/rest/|m/|webhook/).*$"
6. Click Apply in the top right corner of IIS Manager to save the change.
7. Restart the web site or IIS Server.

In the image below, both Web clients have been installed in a virtual directory called "mfiles". The picture on the left shows the URL Rewrite condition with the default values that the configuration wizard sets. The picture on the right shows how to correctly add the virtual directory name into the conditions: