Overview
When you set up web access and enable both clients (Web and Classic Web), sometimes you start getting 404 (not found) errors when trying to access Classic Web or it otherwise does not work. For example, an error like " The specified CGI application encountered an error and the server terminated the process." is given by IIS, potentially after waiting quite some time. Sometimes the web browser request may simply time out without any error messages seen in it.
If you set up only one of the clients, they may work fine separately, provided the requirements for that particular client are met (e.g., traffic on port 7767 is allowed between the servers for Web, and on 2266 for Classic Web).
Tip: The "Share Public Link" feature is part of the classic web, so they work (or not) together. If the "Shared Links" do not work for you (a common symptom that is a first complaint that you may receive), then you are likely hitting the same issue where the entire classic web access does not work.
Details
If both web clients are set up, there will be outgoing HTTP(S) traffic from the M-Files application server to the IIS server. The traffic is pointed to the "Site binding address" specified in the M-Files Web configuration wizard in M-Files Admin. There has to be a valid binding for the site binding address and port in IIS. This traffic from M-Files application server to IIS does not occur when only one of the clients is set up. This is the traffic used by the Classic Web client when the new Web client is installed on the same environment. If this traffic is somehow blocked or broken, you will run into the issues described above.
Most Common Solution
The most common issue is that something blocks the traffic between the M-Files server and IIS, usually a firewall, and/or a misconfigured site binding address, or the DNS name used points to a different computer (not IIS, but a load balancer, firewall,…).
The following is a basic example of a set of settings that seem to work most often. You can see more information and options in the next section.
Step 1: Make sure you have a site binding in IIS for the M-Files Web Access site that is accessible from the M-Files server. A common one is to use the HTTP protocol, the IP address of the IIS computer, no hostname and a custom port on which traffic will be allowed only from the M-Files Server. Example:
Step 2: Ensure that the URL rewrite rule is like
Setups made with old instructions, or other attempts to fix this might have caused the address to be different. It must always be like this.
Step 3: Ensure that the addresses given to M-Files are correct and are full URLs with a protocol, address that matches the settings above and port. For example:
More Information and Troubleshooting Options
Step 1: Basics
Ensure you read, understand and follow the User Guide documentation for setting up the web clients and the nested articles (about the IIS components and the specific tasks you need to do).
Go through them first, before making changes, to understand the entire process and make decisions early to know who to involve:
- The Intro to see what you want to do.
- The IIS Modules article to install IIS components (e.g., your local sysadmin may be needed to assist).
- The appropriate article for the setup you have (e.g., the local network admin/sysadmin may be needed for routing/site binding/firewall).
The "Site binding address" must be a full URL like "http://<IP of IIS>:<port>". An IP often works better than a DNS name (more in the next sections).
The App server address must also be a full URL ("http://<mf app server IP>:7767"). It is never "localhost" - if IIS is on the same server as the vaults, you do not select the checkbox for a proxy setup. The local loopback IP (127.0.0.1) is used only for the UrlRewrite in the IIS site.
The web access setup wizard will not touch the RPC over HTTPS setup, do not worry about it. But consider migrating to a more modern protocol like gRPC. Note, however, that the usage of RPC over HTTPS may alter DNS names which can cause issues (more in the next sections).
Make sure M-Files Web Access is set up only on one machine where IIS is, not also on the separate M-Files application server.
Step 2 Clean Up
If you had an old setup, you could go back to it by performing the same manual steps as a temporary workaround.
The wizard tries to clean up any old setup, but sometimes it may not have enough rights on the system, so you may need to delete the "vnext" and "wopi" web applications that you had made manually - those are no longer needed.
Double check that the UrlRewrite rule in the M-Files web access site points to 127.0.0.1 and not to a different IP or address (if you had it set up manually years ago, it may have pointed to the application server). The wizard tries to fix that too.
If enabling just one client (Web or Classic Web) makes it work (mostly applies to Classic Web issues), then likely the problem is the site binding address and networking (see below).
Step 3 Local Networking
3.1 Ports and Traffic
If the Web client is set up, there will be HTTP traffic from the IIS site to the M-Files Server on port 7767 with HTTP protocol for web access and on port 7768 for Office for the Web services.
If Classic Web is set up, it uses TCP/IP traffic from IIS to M-Files Server on port 2266 by default, regardless of whether the new Web client is set up or not.
If both clients are set up, there will be HTTP(s) traffic from the M-Files Server towards IIS on the address and port and protocol given to the "site binding address" in the wizard.
Ensure this traffic can go through and that custom HTTP headers are not stripped. Blocked traffic usually results in timeouts, stripped headers in redirect loops.
Use a custom port for the site binding (instead of the default HTTP port 80) and allow traffic to it on the IIS server only from the M-Files application server.
3.2 Commands to check ports and DNS names
You can use a network test on the IIS server to ensure you can reach the M-Files Server and vice versa. Ensure traffic is allowed. If it isn't, discuss with your local network administrators to get an understanding of the network, DNS names, routing and firewalls. Sometimes it may even be something counterintuitive like traffic from localhost going to localhost being blocked by a firewall.
First, check that network traffic can go through.
For example, here 1.2.3.4 is the IP address of the M-Files Server).
In cmd:
telnet 1.2.3.4 7767
In PowerShell:
test-netconnection -computername 1.2.3.4 -port 7767
When testing from M-Files Server, use the site binding address and port you gave to the wizard. For example, if you gave it http://10.11.12.13:9876 the commands could look like
In cmd:
telnet 10.11.12.13 9876
In PowerShell:
test-netconnection -computername 10.11.12.13-port 9876
You can also check what DNS names resolve to, for example, if you gave "http://myVaultDnsName.com:80" to the site binding address, you can use
nslookup myVaultDnsName.com
on the M-Files Application Server to see what IP address it resolves on to confirm that such traffic will go to the actual IIS server we want it to go, and not to another node (such as a firewall or load balancer) that won't know what to do with it.
3.3 Other Tips
Try to emulate the common setup depicted above, practice has shown it solves most issues.
Check what IPs the DNS names resolve to on each computer, that ports are open, that IIS has a suitable site binding that receives the traffic (see its text logs or Failed Request Tracing).
Use the IP address of IIS in its own site binding settings for the app server traffic over HTTP (the site binding that you give to the wizard, not the public HTTPS one you may have), if it is left blank sometimes IIS does not receive the traffic at all.
Make sure IIS responds to the "site binding address" with the Classic Web site or with a blank site you can make. You can use the commands shown above or open it from the M-Files app server.
Use a custom port for the plain HTTP traffic for the site binding address for M-Files, and ensure firewalls only allow it from the app server.
Often the DNS name resolves to a firewall or proxy, not the IIS machine, which is why IPs are often better. You need the site binding address you give to the wizard to resolve directly to the IIS machine from the MFServer machine.
Avoid using "localhost" as a DNS name too, it is sometimes changed via the Windows hosts file to something else (usually when RPC over HTTPS is in use). Prefer the loopback IP address 127.0.0.1.
Step 4 TLS (HTTPS) Certificates
The TLS certificate used for gRPC (see more here) is not related to the web access set up and so cannot be used for the HTTPS connections between M-Files Server and IIS.
A self-signed certificate cannot be used either.
If the IIS web site uses a self-signed certificate (or the certificate is not trusted by all components on the system for some other reason), this will break the traffic coming from M-Files to IIS. To resolve this, either:
- Use a certificate from a trusted Certification Authority, instead of a self-signed certificate. Note that this likely has a cost, and also may not be possible with IP addresses.
- Create a binding for the IIS web site that uses HTTP, instead of HTTPS, so the self-signed certificate is not used when M-Files Server connects to IIS. Use this HTTP binding in the M-Files Web Setup wizard as the "Site binding address".
Step 5: Windows Event Log
Monitor the Windows Event Log on the IIS and MFServer machines when you run the wizard and when you try to access a resource and there is an issue. There may be entries to point you in the right direction.
For example:
- Source "M-Files gRPC Http Server" will record entries when you run the wizard.
- There are entries upon start and completion, on some slower systems this may take some time, so if you try before the action is completed, you may see errors, while things may be OK later.
- When an error happens, some entries may point you in the right direction - such as connection reset being likely caused by an untrusted certificate; timeout likely being caused by network connectivity issue such as a firewall or wrong DNS name.
- Source "M-Files" can show application errors, such as bad data sent to the REST API, authentication issues, missing mandatory properties on objects you try to create, etc.
Step 6: Edge Cases
There are some rare situations that you may encounter, such as:
- There are some considerations when setting up M-Files Web in a virtual directory. See this article for more details: M-Files Web clients installed in a virtual directory.
- Avoid this setup if you can, it can often be replaced with vault-specific DNS names which are often desirable anyway, and sometimes even mandatory for some features.
- If you use PSK (Pre-Shared Keys), make sure to add them to the browser via their link. If they are in use, but the browser does not have them (e.g., an incognito/private window), the Classic Web will appear as if it is not functioning. Disabling them for a little while to test (needs iisreset) can also show if this is the case. Note: You can consider whether using a more modern security approach like OAuth can be employed instead.
- Use M-Files Server versions later than 23.3, and try to keep them updated (there are some known issues in earlier versions). Note also the support lifecycle of the product, which is 2 years at the time of writing.
- Features released after the introduction of this setup (22.10) may not work with older setups so you may need to redo them. At the time of writing such examples are the Copy Link and Visitor Link features.
- Special routing that changes the URL can break features, for example /article/Preview-and-file-download-does-not-work-in-when-proxy-changes-URL-session-not-found-error.
