Installation Questions
Frequently asked questions related to Keyfax installation.
Can I install Keyfax within my own Azure environment?
Yes. Keyfax can be hosted within a Azure IaaS environment. The Keyfax web server will require at least 1 virtual machine. The Keyfax database can either be hosted on a virtual machine or within a SQL Azure database depending on your preference.
What specifications are required within Azure?
Please see our recommendations within how do I install the websites or SQL Server database components of Keyfax?
Unless by prior agreement, this will be done for you by trained technicians.
We are moving our Exchange Mail Server onto another machine; what if anything do I need to do?
If the mail server name or IP address is changing, it will be necessary to update the Keyfax configuration files to suit; technicians or support staff will do this for you.
What (if any) Database Maintenance Plan do you install on our SQL Server?
Normally, you will assume responsibility for setting up any maintenance plans as requirements/procedures will normally be determined by your company policy; please consult your DBA. Performing regular backups will ensure that the transaction log space used will be freed and reused, thus avoiding continuously auto-growing the log file which can become enormous and have a severe impact on performance.
Why am I seeing an error 'Invalid Instance/Invalid connection?
The full message is likely to be displayed if you are attempting to connect to a clustered SQL Server and may be seen in the Admin Tools User Maintenance page or anywhere within Contact•View:
Microsoft OLE DB Provider for SQL Server error '80004005'
[DBNETLIB][ConnectionOpen (Invalid Instance()).]Invalid connection.This is a known problem that is unique to clustering. The reason is that the cluster manager will answer on one IP/port and then hand-off communications to the actual (physical) server, which may communicate on a different port. The fix is to specify the port no. (usually 1433) on the connection string. It looks like there might not be a fix, For more info, check out this Microsoft Technet article: http://support.microsoft.com/kb/318432
We need to install Anti-Virus software on our Webserver (IIS), - are there any considerations?
We recommend that you add the folder KeyfaxData (and all it's subfolders) your (IIS) Webserver to the on-access scanning exceptions list (certainly for Read operations); this has led to performance issue in the past. If there’s an option to exclude process W3WP.EXE too, that’ll save a few milliseconds. It will be worthwhile running comparisons before/after AntiVirus changes to ensure that the server performance and access is not unduly affected.
We need to relocate the Keyfax application onto another web server. Is is just a case of copying over the KeyfaxData folder structure, creating the website in IIS and updating server names in files and configuring IIS?
No! There are many reasons why it is necessary for Omfax technicians to undertake this work. This would include:
Security implications, i.e. IIS, folder permissions, restrictions by IP address (especially for DMZ servers)
Linkages between instances of Keyfax (e.g. intranet and DMZ)
Admin Tools access (application rebuild or reconfiguration may be necessary)
Client access
Custom DLL registration
Can we use SCCM to install?
Yes but be aware you need to use the /qb switch when installing. For example msiexec.exe /i “Keyfax Admin x64.msi” /qb.
We have a number of Windows Server® patches to apply; could any of these cause issues with the Keyfax software?
Whenever possible, we would recommend testing or at least backing up server machines prior to any patch updates. In the unlikely event of any issues, we would endeavour to resolve any issues under support/maintenance contracts.
My SQL Studio Management Studio will not connect to another SQL Server on my network; I get an error telling me that the server does not exist. I have checked and both servers will accept remote connections.
Try enabling Named Pipes and TCP/IP connections on both SQL Servers.
General reccomenations and best practices for data backup and recovery for on-premise installations of Keyfax
For on-premise installations of Keyfax hosted on customer owned infrastructure it’s the customers responability to implement a robust Business Continuity and Disaster Recovery (BCDR) plan.
A robust BCDR strategy for a high-availability ASP.NET and SQL Server stack is not a single solution but a layered approach. It combines proactive High Availability (HA) techniques to prevent downtime from localized failures (e.g., a server crash) with reactive Disaster Recovery (DR) plans to recover from catastrophic failures (e.g., a datacenter outage).
The entire plan must be driven by business requirements, specifically the Recovery Time Objective (RTO) and Recovery Point Objective (RPO). We've provided various gneral reccomenations and best practices below as the approach you choose will vary depending on your infrastructure and business requirements.
Keyfax Web Sever High Availability (HA) Best Practices
Load balancing
Multiple Web Servers (web farm or scale / availability set )
Keyfax Web Server Disaster Recovery (DR) Best Practices
Geo-redundancy
Global traffic management
Automated fail over
Keyfax Database Server High Availability (HA) Best Practices
SQL Server Always On Availability Group
SQL Server Failover Cluster Instances
Keyfax Database Server Disaster Recovery (DR) Best Practices
Implement SQL Server mirroring to provide real-time database replicas
Implement short and long term retention policies
Use a cloud native database solution such as a SQL Azure database
Implement a BCDR Plan
Technology alone is not a plan. You need documented processes and a commitment to testing these processes. We've provided some general guidance on preparing a BCDR plan below.
Create a Formal BCDR Document:
Team & Roles: Define who is responsible for what during a disaster (e.g., technical lead, communications lead, business stakeholder).
Activation Criteria: Clearly define what constitutes a disaster and who has the authority to declare it.
Communication Plan: How will you notify employees, stakeholders, and customers?
Step-by-Step Procedures: Create detailed, technical checklists for failing over the database, web tier, and DNS.
Failback Plan: Document the process for returning to the primary site once it's restored. This is often more complex than the failover.
Automate Everything:
Use Infrastructure as Code (IaC) tools like Azure Resource Manager (ARM) templates, Bicep, or Terraform.
This allows you to rebuild your environment in a consistent, repeatable, and fast manner, reducing human error during a high-stress event.
Test, Test, Test:
An untested plan is a useless plan.
Regular Drills: Schedule DR tests at least twice a year.
Isolate and Test: Test failover in an isolated network environment to avoid impacting production.
Full Failover Test: Once a year, consider performing a full, live failover where you run production traffic from your DR site for a period.
Monitor and Alert:
Implement comprehensive monitoring on both your primary and secondary sites. You need alerts to fire when key health checks fail, which is the trigger for activating your BCDR plan.
Last updated