I was searching for the string "Cannot contact web server" and found your thread. Unfortunately it doesn't help me, but I might be able to help you. It appears that two different web apps (RDweb and FMS) are trying to share the same IIS "Web Site". Sometimes this will work, but FMS uses an ISAPI filter that intercepts all requests to the web site, including to the sub folder or virtual directory RDweb and this may be causing RDweb to never get the request. Thankfully, IIS supports multiple web sites hosted on the same machine. You will need to select a method to differentiate requests to the two web sites. Options include different IPs, ports, or host headers. The simplest to get started is probably ports. I would recommend moving the RDweb app to a new web site in IIS. Moving FMS instead would be an option except that the developers of the FMS "Deployment Assistant" didn't provide a method to select the web site that FMS installs inside of. It seems that the "Deployment Assistant" looks for the site named "Default Web Site" and clobbers whatever might have been in it previously. A better FMS "Deployment Assistant" would list the existing web sites and ask whether you want to use one of them or create a new site. Same for the app pool. Because the FMS "Deployment Assistant" is so primitive I would recommend ensuring that you have nothing of value running in the web site labeled "Default Web Site" prior to running the FMS "Deployment Assistant".
BTW, making the change to RDweb may fix Remote Desktop Services, but I doubt it will fix FMS IWP. The "Deployment Assistant" is supposed to "contact the web server" via unspecified mechanisms. If the web server (IIS I believe) can be contacted, then the "Deployment Assistant" proceeds to create an IIS application named "fmi-test" that maps to "C:\Program Files\FileMaker\FileMaker Server\Web Publishing\web-server-support\test\fmi-test" and runs under "DefaultAppPool". For some reason, both the "Deployment Assistant" on both your server and mine cannot "contact" the web server and so the IIS application is not created. Even though the application is not created, it then proceeds to "test" the IIS application by attempting to retrieve the file test.xml in the root of this IIS application that wasn't created. Of course this fails. I've created the IIS application manually and the test suceeds even though the web server cannot be contacted. If the test were to succeed and we elect to continue deployment by pressing the Next button, I believe that the "Deployment Assistant" creates a virtual directory called "jakarta" and installs a couple ISAPI filters in the root of the "Default Web Site".
Another criticism I have of FMS' deployment assistant is that it doesn't need to stop the web server, but it does anyway. By web server they mean IIS and all the web sites it's hosting. So not only does the "Default Web Site" get stopped without warning, but so do all web sites. This is a very crude approach to installation. Furthermore, the test step is broken. If the test passes, then we are informed that it succeeded, but if the test fails, we are informed that FMSisSTUPID, or whatever token you wish to be parroted back.
Many thanks for your elucidation - really appreciate the time you took to look into and explain this. FileMaker should take note.
My solution was pretty simple - stop using FileMaker Web Publishing and move to a more robust platform - Lasso at first, now ASP - that doesn't affect other services on a mission-critical server. WPE has been flaky for as long as I remember.
Thanks again Eve.