Windows - Installing db files on a different volume

I'm working on a system where every couple of weeks a client looses connection to the server. If that happens, users are loging in again and then, a user appears several times in the server admin console and during the next backup schedule, that user can not be disconnected - server has to be rebooted...
If that happens, often some portals are not displayed or a FileMaker script does not finish, blue cirle mouse-pointer appears, quite some time later FM is no longer responding. It's not a specific file that 'hangs', but it's always one of the bigger files

  • The whole system is virtualized, server, clients, volumes,
  • DB files are something more than 20GB, several separated applications (single file systems with some common data in a separate 'menu file').
  • OS is Windows Server 2019, admin console says CPU about 5-20%, RAM usage low as well
  • network is 10GB, fibre
  • event log shows that, but as long as the Server runs without problems, nothing special
  • checks with a copy of the db's seem to be fine, no issues

The issues started about a year ago, when the change from Win 8.1 to Win 10 was started and (covid...) users were in home-office, with online-meetings...
System response is not really crispy. It was not fast before, but rock solid.
I was not involved in the Win 10 change, I realized that as the first user called because of some pdf problems..

The Server does never crash! It's just that users can't be disconnected during the backup. After restarting the server machine, everything is well..
I have only limited access to the server

I asked the IT to check the network, switches, asked for firewall, anti-virus. I got the gut feeling that something in the infra-structure is problematic, but no response besides of 'all fine'

Because of Win 10, we had to move to FM19 (19.4 at the moment) but the server remained on 18.x. The reason for the move to 19 (was planned, but later) was an Adobe product, seemed to be fine with 19.x but not with 18 (I'm not quite sure about that)

Anyway. On the server, FMS is installed on C: but the databases are on D: (virtualized..). I tried to get more disk space for C:, but the IT does not allow that.
Installing was done by some IT staff, copying the FM files into the data directory

I asked for a test-vm for Server 19.4 and installed the FMS by myself, loaded the db files via FM client on drive C: All went smooth although took quite some time (db files 20+ GB). Tests with FM clients seemed quite fast, smooth - but only me as user

Since the IT did not like the db files on C:, I removed the files (via admin console) and installed those files again via FM client - on D:

  • uploading failed
  • the windows explorer window became blank during the upload process
  • tried several times, no chance
  • then, I installed the files one by one (smaller files at once, bigger files (bigger than 3/4GB) file by file
  • this way, it worked. Lost one full afternoon

I'm thinking that both (upload on server and loosing connection) have the same source...

I had this once, when ESET anti virus was installed (socket not available), only with bigger files. This was just a file-transfer, no FM involved

Does anybody have similar expierience, tipps?

Thank You so much for reading!

Is ESET running on the server ? If yes that is not a great idea. Nothing but FMS should touch open FM files. I understand that they wish to have ESET running on the server, but then FMS directories should be added to the list of directories ESET should not scan.

Having the files on a different drive than C: should be a matter of configuring FMS. The alternate directory should have the right permissions needed by FMS applied, the same being true for the files also.

It's unfortunate that the IT department does not seem collaborative with you. I hope this is something that you can fix.

IT said that no anti virus is there. The ESET thing was on another system, no fms - but similar effects while file-copy

IT is short handed (many projects, limited resources), they help immediately as soon as there is a problem (server reboot). It's not so that the IT does not collaborate!

I see. Copying means the source is read so the file goes through ESET, which slow down operations. On Windows an AV always add time to operations Some are really good at slowing down. I have ESET on my Windows computers, quite a competent product.

On Macs, no AV so everything runs faster, on an M1 it's unbelievable !

I'd suggest getting as much information as you can to Claris support. I doubt that they can provide an immediate solution. What I would be asking them to do is to recommend a strategy for you as the system maintainer. What are the most likely causes? Can they be mitigated? What should IT be looking for?

I know that stopping and restarting the server is an effective strategy for difficult problems. On one machine that I maintained the WPE would work perfectly for about ten days, then it would stop disconnecting clients. We went to a lot of effort to trouble shoot the problem without success. As a work-around we scheduled a weekly restart for the machine and avoided the problem. Could this be your solution too?

Have you set up Windows perfmon to collect information of the server? It may tell you what happens.

Thank You so much for answering!

It happens every 2-3 months, so we tried to schedule restarts. But we got a couple of those issues, where shortly after a restart it happened again.

There are other issues as well outside the FM world, users will loose the connection to a server (outlook, Win explorer, etc as well). Mostly, after some time the client will unlock/restart(?) again and users find themselves on the same application, with the same data, as befor that 'big hickup'

I'm not sure, but FM is very delicate when it comes to hickups - and the fact that I could upload data to the fms without any problems as I had everything on the same volume, but could not upload when there was another volume part of the game, that puzzles me.
(I asked the IT and they said that server and clients are on the same backbone)

I have to point out that IT is really not a bad IT - but several parts of the IT-processes are outsourced to third party players (firewall, network, Win10 install, (AFAIK))

I have no admin rights on the server machines (only on the test server and only until it goes 'public')

I will play with perfmon as @samfmp suggested - on the test server where we are only 2 people, but I will ask some kind soul from the IT to set that up on the production server

Since we are on a version mix, I did not ask/call Claris - thats one reason that I forced that test with SRV 19.4. And while installing db files via FM client, something hickuped again...

Therefore, I try to get more infos/expierience with mixed virtualized volumes

First, I was thinking that the use of 'Teams' is one of the reason - but the last time it happened, it was late friday afternoon (most users already in the weekend...)

Often, we get the blue-circle-cursor for quite some time (maybe 30-60 seconds, sometimes even longer) while doing 'normal' work (opening db files, checking log-entries, etc)

Thank You so much! Will check perfmon!

1 Like

Have you compacted the large files and checked if / how it affects the issue?

Virtualized… the drive may be on a different machine than the server, hence there may be increased latency for this server. Have you checked the server's cache setting? Caching would have an impact on performance in this case.

Let's assume different machines and network traffic unprioritized. The network's speed capacity is 10G but overall trafic may still experience bottlenecks. Perfmon on the drive system should give you insight into the drive's performance.

Hope this helps.

Thank You so much for replying!


  • db's are compacted, unneeded data deleted (was 25-30GB before)
  • did not make any difference (happened before installing the test-server)

IT said that all data is stored on devices that are on the same backbone (whatever that means). Since I'm not in the admin-group, I have to ask the IT for perfmon. As a side-effect, they ordered some software for monitoring - afaik not yet installed

Same backbone means the same network as the server. That's an important piece of the puzzle. This means the server and the D: drive are on two separate machines connected via a network. Latency and network congestion are things that need monitoring in this setup. I am betting the D: drive resides on a shared volume too… so volume congestion is another thing that needs monitoring.

Hope this helps.

1 Like