Running QuikFile on a Server

When running QuikFile on a server, there are two issues to be aware of: resource usage and multiple logins.

Resource Usage

QuikFile doesn’t require much RAM. However, two things can noticeably degrade system performance: scanning for new files and OCR.

If you have many hundreds or thousands of folders that QuikFile has to scan through to look for files, the disk activity can be taxing on the system. We recommend that you set the schedule to "Every n Minutes" and set the interval very high - as much as 999 minutes. This will ensure it only scans about once a day. Alternatively, set the schedule to "Manually" and re-run the job whenever the queue gets low.

Also be aware that OCR is very processor-intensive. For this reason, we often recommend running QuikFile on a dedicated workstation instead of a server.

Running as a Service

You can have QuikFile run as a service, which has the advantage of not needing to maintain an active login, not to mention that QuikFile will pick up where it left off after a server reboot.

But there are two pitfalls when running QuikFile as a service, pitfalls which users frequently fall into:

No Mapped Drive Support

Mapped drives are a user preference in Windows. They don’t exist for a service. So if you need QuikFile to access a drive on a different machine, you’ll have to use a UNC path instead of a mapped drive:

//machine-name/share-name/folder

There are many good tutorials for using UNC paths on the Web.

No Credentials

If your files are in a protected folder, the service won’t be able to access them. This is true whether the files are on a different machine or on the server itself. If file access is limited to logged-in users, your QuikFile jobs will fail.

There are two ways around this: first, remove the access restrictions if they’re not really necessary. Second, set QuikFile’s service to run under a specific user’s credentials. The way you do this varies by Windows version. Do a Web search for "run service under user account" for guidance.

Running Under a User Account

If you don’t run QuikFile as a service, it will run under a user account. There are some pitfalls here too.

First, if you use QuikFile on a server where multiple users log in, either at the terminal or remotely, it is critical that QuikFile only be installed under a single user account.

If you install QuikFile for All Users, you’ll see undesirable side-effects. Each user that logs in will get their own instance of the QuikFile Agent, and those Agents will all start working on the same conversion jobs and conflict with each other. This will also degrade system performance terribly.

Proper Configuration

To ensure that QuikFile is only running under one user account, verify the following:

The Windows Registry value at HKEY_LOCAL_MACHINESOFTWAREFileCenterIsCurrentUser should be set to 1

If the folder c:ProgramDataFileCenter exists, move it to Users[username]AppDataRoamingFileCenter for the user who will be running QuikFile. For older versions of Windows, those folders arec:Documents and SettingsAll UsersApplication DataFileCenter and c:Documents and Settings[username]Application DataFileCenter.

Stay Logged On

Once you’re done configuring QuikFile for a single user, you’ll need to log in as that user and stay logged on. If you log off, conversions will stop.