We support quite a few macOS systems that are bound to an AD (Active Directory) domain. Occasionally, one, two, or perhaps several would lose the ability to authenticate users with AD credentials. Often this was with one of the FileMaker Servers, where external authentication was being used for either user access or FMS Admin Console access. I’ve explored ways to fix this, without restarting or disrupting other services.
If you have a FileMaker server that you want to ensure high availability, Amazon’s AWS Route 53 service has some functionality that you’ll want to know about. For this post, I’m going to show how you can set up monitoring and alarms for the XML interface on FileMaker Server.
The short version of this is that you probably want to upgrade to High Sierra (macOS 10.13) if you need to do much of anything with the built-in macOS version of Python and any network tasks.
Continue reading “Overcoming TLS Frustrations with Python and macOS Sierra”
In addition to the more typical external authentication methods, FileMaker supports client authentication using OAuth accounts from Google, Amazon, and Microsoft. In this instance, I needed to set up a FileMaker Cloud server to use a company’s directory accounts, which were hosted at Azure. In order to set this up I hit a couple of minor complications, which I’m going to cover here.
Recently, I needed to revert a database file hosted on a FileMaker Cloud 16 server. Due to a problem I was having with the Download function however I had to take a different route from the usual method.
I needed to set up some monitoring for FileMaker Server that made moderately heavy use of the XML interface for Custom Web Publishing (CWP). The server was mostly working well, but was due for a rebuild, or at the least, an upgrade, but the client wanted to squeeze out one more season before we did this.
Continue reading “Monitoring FileMaker’s CWP Connectivity”
Typically, you buy an SSL certificate for a server from a SSL vendor. However, some companies may decide that they want to issue their own SSL certificates. Often this is because the domain is only used internally, and most vendors don’t easily allow (if at all) the signing of server certificates for non-public domains. Additionally, issuing your own certificates can remove complications caused by the certificate verification process used by most vendors, and there are no fees needed for each certificate.