EA and Running Scheduled Scripts

[brian rich]

We have a third party database hosted on our production FMP11 Server Advanced which is used by the development team.

The database can be accessed either by a user login or using External Authentication. Through the user account, anyone can log in by just opening the database, as it is set to open with a preset user account. If you are a member of the appropriate EA group then you will also be able to log in by just opening the database.

A feature of the database is the ability to turn off the user account so that only EA users can log in - this allows us to limit access to the development team simply by making them members of the EA group. This seemed fine until we discovered that the backups of the files can't be accessed directly as we don't have a Filemaker user login to open them as both the admin and user logins are not disclosed to us. Our workaround for this is to enable the user account prior to backing up, then disabling it afterwards. This means we can access the backup files locally.

We'd like to automate the process by running a scheduled script on the server to turn on the user account prior to backup, then run a second script after the backup to turn the account off again. However the schedule requires that we authenticate, we don't have the admin account and the user account is turned off. Can we authenticate a server side script using an EA account, and if so how should this be set up?

TIA

Brian

[IdealData]

Why do you want to open the backup files?

As this is a 3rd party system and you don't have the admin and user logins then you should be directing your question to the development team.

[brian rich]

In this particular application, we will be rebuilding the complete dataset in the files every day, so the backup files are a snapshot rather than something to go back to in the event of a problem. Since we will need to reference and compare files together, it isn't convenient to load the backups onto the server just so we can view the data.

I'm just trying to find out whether the server can authenticate a schedule using EA. I think that's a Filemaker rather than a development issue.

Thanks

Brian

[Steven H. Blackwell]

If you are a member of the appropriate EA group then you will also be able to log in by just opening the database.

If this proves to be so, then something is rather seriously amiss here. Presuming there is an auto-enter set of credentials, these will always take precedence. You can use an account in an External Group to access the file however by holding down the appropriate modifier key for the specific OS. THis causes the credentials dialog to appear.

On the other item of authenticating the server side script from an External Account, that should work. The Account should have sufficient privileges to do whatever it is you want it to do.

Finally, the behavior you see regarding the ability to access the backup files when they are not hosted is the expected one.

There is a White Paper on External Server Authentication that covers a great deal of all of this. It might prove useful to you.

Steven

[brian rich]

Thank you for the reference to the Server External Authentication white paper - the most recent I could find referred to the Filemaker 9 Product Line. That told me how to authenticate a script schedule on the server using EA, and I assume that the same applied to FMP11 Server.

Looking at this, I noticed that we hadn't used UPN/UNC formats when specifying the EA user name. However changing this still resulted in a Warning error 661 with the message:

Client "Enable User Acct" authentication failed on database "Program.fp7" using "Admin"

We weren't loggin in using Admin, so the problem may be that the authentication order for the accounts is not correct. As I don't have access to the admin account for these databases, I'll need to pass the problem back to the program developers to see what solution they come up with.

Thanks

Brian

[Wim Decorte]

Can we authenticate a server side script using an EA account, and if so how should this be set up?

Yes, for hosted files, No for non-hosted files like backed up files. Like Steven mentioned: you seriously do not want to access your backup files directly unless you are 1000% sure you have another good backup set to fall back on.

[Steven H. Blackwell]

Client "Enable User Acct" authentication failed on database "Program.fp7" using "Admin"

Be sure that none of the files left the default Admin with no password enabled in the auto-log on feature. That's the usual cause of this error.

Steven

[brian rich]

@Steven:

According to the developer, the authentication order is: "the Admin account is first in the list, but it shouldn't use that as it has been removed by the developer tool. After that is the two EA accounts, followed by the single user "User" account"

Perhaps the missing admin account is the issue?

@Wim

The application is a separation model, so in theory we only need concern ourselves with the data file. If this becomes corrupt we are not clear about how to recover the data from the corrupt version of the file - a recovered version of the file would also need to be hosted to allow us to extract the data, which seems to suggest several potential problems. Our reasoning was that being able to enable the user account using the scheduled script before backup would mean that the recovered file would be accessible as a non-hosted file which would make the recovery process easier. Any thoughts on how best to manage this would be appreciated.

Thanks to both for your advice.

Brian

[Steven H. Blackwell]

You're looking at the wrong item. It's not the Account list in Manage Security, it's the auto log-on in Preferences that you need to examine. Be sure that the default log-on was disabled. If it wasn't, then that's the likely cause of the error message.

Can you not open the "recovered" version of the data file as standalone file to extract the data?

Steven

[Wim Decorte]

@Wim

The application is a separation model, so in theory we only need concern ourselves with the data file. If this becomes corrupt we are not clear about how to recover the data from the corrupt version of the file - a recovered version of the file would also need to be hosted to allow us to extract the data, which seems to suggest several potential problems. Our reasoning was that being able to enable the user account using the scheduled script before backup would mean that the recovered file would be accessible as a non-hosted file which would make the recovery process easier. Any thoughts on how best to manage this would be appreciated.

While restoring data from a recovered file is something to consider, it is truly the last-ditch attempt to restore. You can leave one FM account in the file with enough privileges to open and export the data. However, you should have sufficient tested and verified backup processes in place that you should never get to a recover. I would concentrate my efforts there.

The application is a separation model, so in theory we only need concern ourselves with the data file. I

As long as the data is concerned yes. But that implies that you have valid backups of the interface files. And since those are hosted on the same server as the data files, it's kinda an infinite loop: if you need to recover the data file because you have no valid backups of it, the interface files will have crashed just as badly and you won't be able to use them.

For authentication purposes, the use of the separation model does not make any difference. Unless you hare using the interface files locally (not hosted) which is a totally different ballgame because you can not use external authentication on local files.

So I'm still somewhat confused on your setup and purpose. What kind of backup strategy is in place?

[brian rich]

@steven: sorry, that I misunderstood - I will ask about the auto-logon preferences.

@wim: Our backup strategy is to backup all the databases nightly after all users are logged off, using a standard backup schedule. Later the same night these backups are picked up by our generic back-up system which dumps them to removeable archives which are cycled off-site for disaster recovery purposes. Every morning the current Filemaker backup is moved outside the Filemaker Backup folder to a separate storage area, and we hold the last two days backups there. (Filemaker server also creates a set of clones during the backup process. A separate system is used to run a recover on a copy of these clones each night so we have early warning if there is an issue with them.) We're reasonably confident we can restore our own systems back to health with this approach, although any advice would be welcome.

We have admin access to all of our own databases, however we don't have admin access to the third party database which is hosted under EA. Our strategy for getting this database back after a crash would be to restore the original interface and data files from the installation as shipped from the developer, then import the data from the last know good backup, which appears to be the recommended way to manage the process. The problem is that we can't get access to the backup unless that is also hosted, which means have two concurrent data files on line at the same time.

The solution that works is to turn on the user account before the backup and turn it back off again afterwards, so the backup is a local file and can be accessed via the user account. However we are doing this manually at the moment - we just wanted to make it foolproof.

TIA

Brian

[Wim Decorte]

We're reasonably confident we can restore our own systems back to health with this approach, although any advice would be welcome.

I know I'm pushing you hard on this, so please indulge me... but test, test, test... then test some more. You won't know how much your DR procedures are worth until you test them and you will be hero when you have to perform them for real.

The point that I've been making at the last few devcons is: "we're good developers, but are we good deployers?"

We have admin access to all of our own databases, however we don't have admin access to the third party database which is hosted under EA.

I don't think you can solve this without involving the vendor for that 3rd party solution. Unless you are willing to spring for a dedicated standby server to host the backup on.

[brian rich]

Hi Wim

I know I'm pushing you hard on this, so please indulge me... but test, test, test... then test some more. You won't know how much your DR procedures are worth until you test them and you will be hero when you have to perform them for real.

The point that I've been making at the last few devcons is: "we're good developers, but are we good deployers?".

I'd say we're learning to be better developers and deployers but still got a lot to work out, and to learn. We've got 90+ legacy databases (yes, it grew like Topsy over ten years), some with 40 or more concurrent users. So for us it is developing the already deployed, rather than the otherway around.

I'm assured by the IT team that their DR procedures would allow us to get the last versions of our Filemaker backups onto a working server within our critical business horizon and it has been tested. However that only gets us back to yesterday and todays transactions are going to be lost - not worked out how to deal with that one.

Your point about testing, testing testing is absolutely right; at one of my previous companies we did do a full DR test. It more or less worked but left us with a few new lessons to learn about the things you can forget.

Brian