3 posts in this topic
I had to migrate a Mac OS Mini Server running Mavericks 10.9.5 and Filemaker Server 13 to Filemaker Server 14.0.4 on El Capitan 10.11.6 today.
It turned out to be an unpleasant and tiring operation, so I wrote a little manual that hopefully can help and save time for other people running into this situation.
Some steps my not be necessary, but the following list describes the road I took, stumbling from one problem to the next.
Rest assured that I left out a lot of swearing and three letter words that were also part of the process ;-)
Backup your databases, stop and de-install any previous Filemaker Server version.
The Filemaker 13 de-installer is located in the Extra’s folder on the Filemaker Server 14 installation disk image.
Install El Capitan 10.11.6 + updates
Do not install OS X server ( yet ) - see the notes at the end of this little manual.
Remove the Java version installed with Mac OS - in my case Java 8 update 111.
Steps from the Oracle website:
In the Terminal window Copy and Paste the commands below:
sudo rm -fr /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin
sudo rm -fr /Library/PreferencePanes/JavaControlPanel.prefPane
sudo rm -fr ~/Library/Application\ Support/Java
Install the version required by the 14.0.4 Filemaker Installer: Java 8 update 60 before installing Filemaker.
Installer is called: jre-8u60-macosx-x64.dmg
After creating an Oracle account and logging in it can be downloaded from:
- Scroll all the way down and click Java Archives
- Click Java SE 8
- Scroll down to Java SE Runtime Environment 8u60
- Click Accept License Agreement
- Download jre-8u60-macosx-x64.dmg
The Filemaker installer is supposed to install this Java version by itself, but in my case it appeared to contain the Java 8 update 31, causing a loop within the Filemaker installer, repeating the process of installing the wrong version.
Get Filemaker fms_184.108.40.2062.dmg.
Use the full installer!
In my case installing an earlier version and running the updater did not work - the updater to 14.0.4 hung during installation.
Filemaker also advises this but unfortunately chose not to put the full installer on their website, so I had to Phone Filemaker support and supply the original sales contract number. After providing these details they mailed a link to the 14.0.4 full installer.
Because I was planning a co-install with OS X Server App I used port 8080 and 8443 in stead of the standard 80 and 443 during the setup.
Also I did not enable web publishing and ODBC/JDBC during installation because I desperately wanted to get the normal services working.
Do not start Deployment when the installer finished but click Quit in the finishing dialog.
Next step is to stop the server process via the terminal, as per Filemaker’s instruction: type or paste sudo launchctl stop com.filemaker.fms in a terminal window, enter and administrator password when required.
In my case I had to restart the Mac and do this last step again after a fresh restart, before the FileMaker Server 14.0.4b Software Patch wanted to run without complaining about the Server being running.
Run the FileMaker Server 14.0.4b Software Patch from http://help.filemaker.com/app/answers/detail/a_id/15575
Note that this installer will update your Java version to Java 8 update 66, in my case this went without any hiccups.
Log in to the Admin console using the FMS 14 Admin Console.webloc shortcut placed on the Desktop by the installer.
Alternatively point your browser to http://localhost:16001 and click Start Admin Console
About co-installing with OS X Server version 5.2
I know the true purist warn against this; in this case the server is under a relatively light load, so performance does not seem to be an issue.
Getting OS X Server to co-exist with FM Server proofed tricky though.
Initially I had OS X Server app installed before trying the last FileMaker Server 14.0.4b Software Patch which caused the installer to hang again.
So I had to command-drag to move the Server App from the Applications folder to the Desktop. After authenticating the Mac detects the removal and presumably stops and repatches all services involved.
Then the FileMaker Server 14.0.4b Software Patch installed, after which I could put the OS X Server app back, re-login to server, re-enable the services, restart the Mac and finally login to the Filemaker Admin console.
Next time I would leave the OS X Server installation as last step; possibly this will be less work.
By Peter Barfield
Hope someone can help with this issue.
I have filemaker server 14 installed on windows 10 ( yes! I know that is not part of the recommended specs by filemaker but it has been very stable for me as I only use it for odd db's when I am out and about from the office) and was working fine no issues whatsoever. I use ports 8080,443 and have port forwarded them through router as well as all the other ports required as per filemaker documentation.
All of a sudden it has stopped working. (no! There have been no windows updates)
I have disabled all firewalls and Sophos(this really doesnt like server for some reason).
I can connect to the server via LAN (ie local network) fine. but connecting remotely has stopped all of a sudden.
I use changeip to create a dynamic IP and that is working fine.
I have completely uninstalled and reinstalled the server as well.
Any ideas as to where i could look to see where the problem may lie?
I have tried to connect with filemaker go V13, 14 and 15 and filmaker pro 14 and 15 from variuos machines (no joy) now i am completely pulling what little hair I have out.
cheers in advance.
Objective: We want to make the whole solution faster, for both web and local FMPro users. Here's what we are working with:
- Machine 1: FileMaker Server 14, Blade server with 512GB ram, 1TB SSD, running Windows Server 2012 R2, intranet connected only, main machine.
- Machine 2: iMac, runs Admin Console only.
- Machine 3: FileMaker Web Engine 14, Mac Pro with 128GB ram, 1TB SSD, running El Capitan, intranet and internet connected, exclusively for web.
- FileMaker file is a single file at 14GB, no data separation currently, containers are stored externally. Let's assume that the file's inner workings are optimized and that we are here to discuss server deployment, server specifications, and server settings.
- FMPro simultaneous users: ~100. XML and PHP total Web simultaneous connections: ~50.
Question 1a) Would there be much benefit to setting the Server Cache from its defaulted 512MB, to 490GB (yes that's GB)? We see 99-100% cache hit when at 512MB. We see consistent 100% cache hit when at 490GB. Disk access is orders of magnitude less when cache set to 490GB, almost none.
Question 1b) Would there be any penalties associated with the above setting? For example, we've heard that regular backups would be missing the latest data changes unless the Progressive Backup feature is used. We've also heard that should the server crash, more data would be lost (except for the backup, of course). We've also heard that FileMaker Server has to use more CPU time to "manage" such a large cache, resulting in less performance, not more. Any of this rung true? Any other penalties to consider?
Question 2) Would breaking the file up into data separation model, smaller chunks, net any performance benefits?
Question 3) If using a smaller Server Cache (say, back down to 512MB), would the system benefit from a RAM DISK (such as RAM-SAN 440) instead of an SSD, and give net better performance than the crazy big Server Cache setting?
Observation: 512MB cache makes FMPro clients faster, but web slower. 490GB cache makes FMPro clients slower, but web significantly faster.
Observation: FM Inc and one consulting firm tells us to set the cache to 90% of this server's ram capacity. Other experienced developers tell us to "manage" the cache at a much smaller number, paying mind to the cache hit percentage. What say you?
Thank you for any insight, folks!
By Brent Hedden
**This is more of a networking question, but I am applying it to FileMaker Server directly
I've got two virtual single machine FM 14 servers under different subnets/buildings that I want to setup to be a hot/cold availability situation. The backup VM is synced from the production every 15 minutes (one of the great reasons to use ZFS filesystem). This server does have a static IP address assigned, but I forgot that I can't use the same IP address under a different subnet. So when the backup server is turned on, it will broadcast to a different IP address. Which isn't ideal, considering it will confuse end users to switch to a different server/IP - I wanted to make this transparent. Unless I move the backup hardware to the same building/subnet, this is going to be an issue that I need help with.
Can I use a DNS round robin technique for this situation? I know it's more for load balancing, but if I change the IP address of the backup to something appropriate to that subnet, then I believe it'll work so the end user only deals with one IP. I do also have to consider WebDirect/IIS and an installed certificate.
If anyone has experience with this and/or can give me some ideas, I would be very grateful!
Our school district has recently started to use Filemaker to automate some student data functions not available in our student information system.
I have run into an interesting problem when exporting tables based on found sets. When running the script using the server Schedule Scripts function, the export table seems to be ignoring the found set I have created in a layout. I have tested the same script functions in the same order in the client and I get an exported CSV that is based on the found set.
Is there something I am missing in regards to context? I have read some of the documentation on the Filemaker site. It seems to state that there is no current context when the script runs, but I am loading a layout which I have then applied a Perform Find and then export using the same table as the layout.
Any insight would be helpful.