AnsweredAssumed Answered

Web Publishing Engine Never Enables for Worker / Azure oAuth Issues

Question asked by EdwardMcPikeJr on Jan 8, 2019
Latest reply on Feb 11, 2019 by EdwardMcPikeJr

Product and version: FileMaker Server 17.0.2

OS and version: Windows Server 2016

Hardware: VMs on Rackspace, both Intel Xeon CPU E5-2630 v3 @2.4GHz (12 processors); 32 GB RAM

  • Master Server has 4 drives:
    • C: 200 GB
    • D (for data): 50GB
    • E (for backups): 400 GB
    • F (for container data): 50GB
  • Worker server has 1 200GB drive

 

Description:

I have installed FileMaker Server on many servers over the years and never had many problems. Lots of experience here, but I must be missing something. After at least 40 hours of troubleshooting, I have finally decided I can't figure it out by myself.

 

I have run into issues trying to set up our development environment to mirror our production environment. I successfully set up the prod environment with the same specs as above, with Microsoft Azure oAuth enabled and correctly configured. I asked Rackspace to spin up the same specs as two new VMs for our development environment.

 

I have now run into the below scenario (which includes two issues) three different ways. After running into the issues the first time, I removed the worker server, uninstalled FMS from that server and deleted the FileMaker Server folder. I also uninstalled FMS from the master server and deleted the FileMaker Server after saving my development files. I then reinstalled on each and had the same issue. Lastly, I asked Rackspace to reimage the VMs. I then repeated the installation process. Here are the details, with slight differences in installation steps each time:

 

Our parent company requires monitoring access (Qualys agent) and logging software (Winlogbeat). I installed these AFTER our production servers were up and running, and everything went fine.

 

For my first installation attempt on the Dev VMs, I installed these first, the installed FMS. For the 2nd attempt, they were already installed, I was just reinstalling FMS. For the third attempt, after the re-imaging, I decided to keep it as clean as possible and only install FMS. However, I got the same results, so I doubt this mattered.

 

FMS Installation steps each time:

  1. Install FMS on Master server
  2. Configure Admin Console as if it was going to be a single server setup, including Microsoft Azure oAuth configuration, and enabling extra folders described above. Also included loading of server settings from our production server, then disabling of all scheduled scripts. SSL cert is an Entrust wildcard cert already in place on 4 other servers running FMS.
  3. Put database files and conf files in place and open database files. Conf files include custom web pages index.html and logoff.html so that our external clients (who only access via WebDirect) won't have to see the WebDirect home page. URL behind the "Log In" button includes a HOMEURL pointing to logoff.html.
  4. Increase cache, enable XML, and disable schedule 1 from the command line.
  5. Close files, stop FileMaker Server, then Restart server.
  6. Test access via FileMaker Pro, FileMaker WebDirect (native, via fmi/webd link), and WebDirect again (via our splash page).

 

ISSUE #1: After clicking Log In from our splash page, it sits there doing nothing for about 30 seconds, then eventually pops up with the regular Account Name & Password login window - WITH NO MICROSOFT BUTTON for oAuth.

 

 

I came across this issue when first trying to setup oAuth with our old single-server production server after it worked fine on our single-server test server, as described here. Back then, I looked through logs, etc, and had these comments:

 

Checked our logs via Chrome DevTools and the VAADIN push is taking 20-30s and this widget set is having a hard time downloading:

com.filemaker.jwpc.iwp.widgetset.client.rpc.UserAndPasswordDialogClientRPC

The push seemed to be coming from this URL (replaced our domain with "yourDomain"):

https://prod.yourDomain.com/fmi/webd/PUSH?v-uiId=5&v-csrfToken=554edbd7-ebb8-4684-a89d-939dda11ae6b&X-Atmosphere-tracking-id=2784f9a6-f74d-4553-af6d-7d14b677ce73&X-Atmosphere-Framework=2.2.13.vaadin5-javascript&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1539719959089

Seems like it's having a hard time building that dialog when coming from our custom URL versus coming from the regular WebDirect access.

 

At this point, I decided to move on since access to WebDirect via the Master Server isn't critical - decided to add the worker and see if everything worked at that point.

 

After installing the worker server, it cannot find the master via FQDN, as the server name is what is grabbed by FMS. It does find it via IP or the name of the server stored in the Admin Console, but issues an SSL warning. I selected to connect anyway, and it said it was successful.

 

ISSUE #2: It was not. Clicking the Enable/Disable button next to the new WPE that appears as a worker toggles to enabled for a minute or so, but the status stays as Unavailable. Eventually, the button toggles back to Disabled.

 

WPEsNotWorking.png

 

I tried removing the worker and reinstalling it a couple of times within each of the three installation events described above. I have opened data and testdata RDC windows side by side and compared files, IIS settings, etc on each. Did the same for web and testweb - all are the same. (data and web are our production pair).

 

We control our firewall at Rackspace and all ports are open and available - you can see the proper traffic on the other sites. Ports 443, 2399, 3389, 5003, 16000, 16002, all open and available.

 

How to replicate: repeat above installation process?

 

Workaround (if any): none

 

Any thoughts??

 

Thanks in advance for any help you can provide.

 

Regards,

 

BafflEd and FrustratEd

Outcomes