We’ve been working a lot lately sorting out some setups for two machine FileMaker Server installs, and we’ve come across some issues and solutions that may be of help to others.
Setup
In particular this is a two machine install, where you’ve got an internal FileMaker Server, and you’re adding an external web server on a different network. This setup gives you a little more security ( by having the public facing web server outside your normal network ) with the advantage of the FileMaker Server inside the network for the maximum speed in serving to the FileMaker Pro clients.
In our case we were using the Alternate configuration, which puts the Web Publishing Engine on the same box as the FileMaker Server. This setup means you don’t have any of the performance advantages of offloading processing from the FMS box, but suits our setup because the server is well suited to running both tasks and isn’t going to be a high load. So we can then use a quite low end web server and easily handle the traffic.
Also note, that in our case, and in lots of situations like this, the FileMaker Server is on a private network behind a router, so you need to have port forwarding setup to map the external IP address to the internal FileMaker Server IP for ports 16000, 16016 and 16018. All the details of this is in the pdf documentation that comes with FileMaker Server.
Issues
When you run the deployment of FileMaker server, you’re asked for an IP address. You can actually use either ip or FQDN ( fully qualified domain name). From there communications from worker to master do some lookups ( domain to IP ) and some reverse lookups ( IP address back to domain ). And if not all of these return the data that FileMaker needs, things might not work as expected.
As an example, we have a FileMaker Server running on the internal private IP of 192.168.1.1 and that network has a public IP of 1.1.1.1. As well the web server is on a public IP of 2.2.2.2. We have domain names setup as :
master.example.com => 1.1.1.1
worker.example.com => 2.2.2.2
But in order for communication between the two machines to work, the reverse DNS for the worker machine should also exist, so
2.2.2.2 => worker.example.com
Because when the deployment runs, it will do a reverse lookup on the IP address given to it, and then a lookup of that domain to get back to an IP address, and then it’s only this final IP that is used to deploy to as the worker machine.
And there are some requirements for the master as well. During deployment, the Master sends the Worker a domain name for it to use in all future communications. But it doesn’t use the one provided, it does a reverse DNS lookup on the IP address and provides that domain instead. So you also need a working reverse DNS on the internal IP address as :
192.168.1.1 => master.example.com
Technically you’re not meant to do a reverse DNS for internal IP ranges, but without this step working the two boxes won’t talk. If you don’t provide a reverse DNS entry for the internal IP address, the master machine provides the internal network IP to the worker, and then after deployment nothing will work.
Future
I’d like to see the deployment process take into account a master ( or worker or both ) that could be behind a NAT firewall and allow for this. This could easily be achieved by asking for ( and only ever using ) a FQDN for both machines. That way these could be explicit and even IP address changes wouldn’t need re-deployment ( maybe just a reboot ).
Notes
In our tests we were using all Windows 2003 Server SP2 and the latest FileMaker Server 11.