Jemmac Software
OPCFailover logo. Frequently Asked Questions

The following sections list the questions most frequently asked regarding OPCFailover. If you query is not answered, we would be delighted to answer it directly.

Downloading and Installing

  • How long does it take to install and configure OPCFailover on a node?
    It takes about one minute to perform the install, and around another minute to configure your first failover group with two real OPC Servers. Configuring the DCOMCFG security to allow the OPCFailover Service access to the real OPC Servers can take a variable amount of time, and will require you to refer to your OPC Server vendor instructions.
  • Will I need to reboot after an install?
  • Tell me some more about the account used by the OPCFailover Service.
    The OPCFailover Service needs to run under a Domain account that is a member of the local Administrators group. Such an account,
    • has security access to registry data under HKEY_CLASSES_ROOT
    • can be referenced in remote (Domain) nodes DCOMCNFG settings
    The account is also granted the 'Log on as a service' local user right.

    During the installation of OPCFailover you will be prompted to enter the account name and password. If the account does not exist it will be created, added to the local Administrators group and given the correct local user rights. If it already exists then the password will be verified and the local group and user rights settings fixed (if needed).

  • Can I install more than one copy of OPCFailover on a node?
    No. There is actually no need to install more than one copy since a single copy can manage any number of failover groups, each of which can contain any number of real OPC servers.
  • How big is the OPCFailover .MSI file?
    Less than 5Mb.
  • My OPC Servers all have the same ProgID. Does OPCFailover support these types of OPC Servers?
    Yes. OPCFailover abstracts common or unique ProgID's to local unique ProgIDs. The failover group then references these local unique ProgIDs.

    This features enables an OPC Client to communicate concurrently with multiple OPC Servers which are normally accessed via a common ProgID [this would otherwise require the OPC Client be capable of overriding the RemoteServerName associated with the ProgID]. You may well find this capability useful even if the failover groups are defined with just one real member OPC Server.

  • Can I tell which OPC server my OPC Client is actually connected to?
    Yes. If an OPC Client currently has access to OPC data it is doing so via the Active OPC Server in the failover group it is using.
  • Can I have more than two OPC Servers in a failover group?
    You can have as many OPC Servers in a failover group as you want.
  • My OPC Servers implements concurrent licence limits based on the use of any of the OPC DA interface. Will the OPCFailover Service use a licence when it communicates to the OPC Server?
    In it's default configuration OPCFailover does not use any OPC interfaces when testing the status of an OPC Server. Because of this it is very unlikely that OPCFailover will contribute to a usage count. To be totally sure you should test this out as the answer will depend on how the OPC Server vendor has implemented licence management.

    If OPCFailover is configured to test 'Status' for a specific OPC Server then OPCFailover will attempt to make periodic use of the OPC interface status call. If you have configured OPCFailover to do this AND your OPC Server implements concurrent licence limits it is very likely that OPCFailover will contribute to the usage count.

    If OPCFailover is configured to 'Read' an OPC item from an OPC Server you should expect the OPCFailover Service to consume a licence.

  • When I uninstall/upgrade OPCFailover will my OPC Clients need to be stopped and restarted?
    No. Your OPC Clients will continue to function and be totally unaware that OPCFailover has been uninstalled or upgraded. If OPCFailover is uninstalled and the Active OPC Server within a group fails then a new Active OPC Server will not be assigned. This will result in the OPC Client attempting a reconnect to the failed OPC Server [just like it would do without OPCFailover in place].
  • What are the best poll periods to use?
    This depends on how quickly you want an OPC Server failure detected and acted upon.  Polling the Active OPC Server every second and setting the polling of the standby OPC Server to 'Never' has been found to work very well and not induce an noticeable load on the OPC Client or OPC Server nodes.
  • I've tried to browse to add OPCServers to my failover group, but the browsing is not working. What do I do?
    This is very likely caused by the firwall settings at the remote node. To perform a browse of a remote node File and Printer Sharing must be opened (TCP 137, 138, 139, 445). Once the browse has been completed the ports can be blocked again as they are not used during the normal operation of OPCFailover. From OPCFailover V1.6 it will be possible to manually specify the remote node name and OPCServer CLSID instead of browsing.
  • Once more, can you explain this CLSID and ProgID thing?
    Yes. When a client application wishes to make a connection to a server, it uses the servers CLSID to identify it. A CLSID is a 128 bit globally unique identifier and as such is quite difficult for humans to remember. To make life easier for people, a CLSID can have a human readable alias associated with it. This alias is known as a ProgID. The client application can then be configured to use the ProgID (human readable alias) to define its connection to the server. The computer will handle the job of converting the ProgID to the CLSID.

    In the OPCFailover world, the ProgID defines the name of the failover group.

  • If I install OPCFailover on a node do all the OPC Clients on that node need to use it?
    Since OPCFailover introduces new ProgIDs (failover group names) any OPC Client that wants to use them must ‘opt-in’ and be reconfigured to target the new ProgID. OPC Clients that are not reconfigured will continue to use the OPC Servers they have always been using.
  • Does OPCFailover support Email/pager notification of failovers?
    Not yet. If you think this would be useful please let us know. It may then appear in a future release.
  • Can OPCFailover periodically read an OPC item to confirm the condition of an OPC Server?
    Yes. You can configure an optional, synchronous device read of and OPCitem to determine the condition of an OPC Server. If the read completes without error and the returned quality is GOOD, then the OPC Server is considered to be healthy.
Purchasing and Licences
  • Can I purchase a site wide licence?
    You can email us and let us know some of the details about your site. We will then provide you a quote.
  • Can I bundle OPCFailover with my own OPC Client installation?
    Not at present, though we are always open to such suggestions; email us with your proposal.
  • I want to ensure my OPC Client will work with OPCFailover. Who do I contact to clarify the coding requirements?
    Email us with your contact details and we´ll call you.
  • I've got an idea for an enhancement to OPCFailover. Whats the best way of getting it into a future release of the product?
    Email us with your enhancement and contact details. We’ll review your enhancement and possibly contact you to clarify your requirements.
  • OPCFailover appears to be very generic and capable of providing failover for DCOM servers in general. Is this true?
    OPCFailover´s design does provide a failover capability for other types of DCOM servers, and indeed the OPCFailover Patent makes this claim.
  • Do you provide an service to validate OPC Clients with OPCFailover?
    No, but we are working with OPC Client vendors to certify OPCFailover with their products.
More information

Click on the links below to find out more details about OPCFailover:

Try & Buy

A trial edition of OPCFailover can be downloaded from this site.

Additionally OPCFailover can be purchased directly through our online store