I need to be able to restart a Windows server running FileMaker server via a script. I would like to run a server side script in the Filemaker Server software.  I was interested in using the 360works ScriptMaster. Any advice, pointers, problems I should be aware of?

In general, this doesn't seem like a good idea: to reboot a server from inside a running process.

Following best practices - to make sure your files are in good shape after the restart - you have to first kick off all FM users, then close the files and confirm that they are all closed, then and only then reboot the server.

But of course by the time you disconnect all connected FM users you will also have closed your own connection...

Thanks Wim, I though also of that conundrum....but what if I put a delay on the restart (something like "shutdown -r +15" or something like that) and then closed all the databases...would that sequence work?

 

I wouldn't trust it, my risk appetite for deployments isn't that big.

One way to mitigate the risk would be to very stringent on the opening sequence: detect an "improperly closed" event in the logs and immediately close the files again and email admins.  But that's a lot of work and upkeep to make sure that works correctly.  So in short I wouldn't do it.

Why do you need to restart the server from inside FM?

Thanks. Yeah, might not be worth it. Was just tryin got do the restart from within FileMaker. Server access is limited but FM is open. NO need to use VPN or any other apps. Not a big deal just trying to make my life one step easier. 

Actually I wish there was a best practice way to do this nightly.  Server updates and patches happen all day long here and some mornings I wake up and a half dozen of my FM servers are frozen.  A reboot generally fixes them, but it can take an hour or more to walk through them, check the logs, and then do a controlled reboot.

4 minutes ago, mr_mike said:

Server updates and patches happen all day long here

In production?  That's the weirdest thing I've heard in a while.  Most organizations plan and schedule server patches and do them in bulk say every week or more likely every month, in a known maintenance window so that the FM team can be involved in gracefully closing the files ahead of time and do some sanity checks afterwards.  Usually in weekends or evenings, when the business is ok with having downtime.

I wish that was the case here.  We have several thousand servers/solutions and cyber requirements that often change hourly.  Hence, an automated nightly reboot would settle in those updates and global policy changes. (alway good to hear from you Wim, I've got a lot of respect for your knowledge)

It can be done, since FMS has an excellent command line and admin API for precisely this reason.  You'd have to do a ton of error trapping and handling with a well-thought through decision tree and procedure for how to handle all the situations you can encounter, like a client you cannot connect, a schedule that you cannot stop, a file that refuses to close, files that are reported as improperly closed on-open,...)

Plus of course a DR procedure if the machine itself doesn't come back up after a reboot.

Running backups before the scheduled reboot, moving the backup off-machine.  Or making hypervisor snapshots safe.  And of course all the external monitoring and notification escalation that comes with it.

There's a lot there that needs to be considered so it's not a cheap ask.  I've done a few High-Availability deployments; they're a ton of work.

Your time is valuable Sir, but if you build this, I'd move heaven and earth to purchase it.  I've got the VM's snaps on hourly.  I've got log monitoring going. I've been trying to conceptualize a data comparative to know what changed in the data if the worst happens.  You are right, there is a lot of moving parts to account for.

You might be one of a very small handful of professionals on the planet that can do this!