Propagating an EFT Site

For disaster recovery, some customers need to perform a unidirectional sync across settings from a live EFT site to another so that a backup system is available.

To propagate an EFT Site

  • Internally, propagation is performed via target server’s REST Administrator interface, so target server must have Web-admin enabled for the feature to work.

  • The administrator must be at least a Site-level Administrator.

  • Administrator account must have Programmatic API Policy enabled.

  • The production and backup servers must have similar (or same) environments (file system structure, network neighborhood, and so on).

  • Both servers must use the same run-time variables to configure environment-specific parameters.

  • On the Server tab, right-click the Site node, then click Propagate.

    .

    • The Propagate Site dialog box appears. Provide the target EFT Server details and a shared folder in which to export the Site, then click Propagate.

  • Target EFT Server administrative endpoint. URL:port such as https://192.168.118.128:4450.

  • Target EFT Server administrator username and password (EFT managed accounts only; there is no AD/LDAP support for administrator accounts in this dialog).

  • Shared folder to export the site to. The target server, receiving server, and the EFT Server service must each have an account that has read/write access to the shared folder.

  • Select the Save target... check box to save the propagation parameters for future reuse. If selected, after successful propagation,

  • All the parameters except for target server administration password are preserved across EFT administrator interface restart

  • Target server administration password is preserved during current EFT administrator interface session

    • The identity is provided by an internal site ID:

    • If target server had no site with matching ID, the site is created.

    • If target server had the site with matching ID, it is replaced.

The following parts of the site are propagated:

Whole configuration database

  • Except for node-specific parameters (“replace existing” scenario)

    • Started/stopped status

    • Listen IP

    • DMZ gateway settings

  • If the value of a filesystem-related parameter of source server site points to source server Configuration Directory (by default, C:\ProgramData\Globalscape\EFT Server\ for standalone deployment and HA cluster share for HA deployment), then the value of target server site points to the target server Configuration Directory

    • The filesystem-related parameters are:

      • Server SSL certificate and key

      • DMZ Gateway SSL certificate

      • DMZ internal SSL certificate and key

      • SAML IdP certificate

      • AS2 certificate and key

      • AS2 Inbound/outbound partners’ certificates

  • For example, if a site of standalone-deployed source server is configured to use SSL certificate C:\ProgramData\Globalscape\EFT Server\Certificates\ssl.crt, then, after site propagation, the site of HA-deployed target server is configured to use SSL certificate <CLUSTER_SHARE>\Certificates\ssl.crt

Site files

  • Server SSL certificate and key

  • DMZ Gateway SSL certificate (only in “create new” scenario as it is a part of node-specific parameters which are preserved in “replace existing” scenario)

  • DMZ internal SSL certificate and key

  • SAML IdP certificate

  • AS2 certificate and key

  • AS2 Inbound/outbound partners’ certificates

  • Email templates

  • HTML templates

  • WTC customization files

Files are propagated path-to-path, i.e., the file located at <PATH> at the source server is propagated to the <PATH> at the target server, except for the files located in Configuration Directory, HTML/email Template Directory, and WTC Customization Directory, which are propagated to the corresponding directory at the target server

  • For “replace existing” scenario, the target server backs up and removes the entire existing WTC Customization Directory

  • For “replace existing” scenario, the target server backs up and removes all HTML/Email template files

For any other file, if a corresponding file already exists at target server:

  • For “create new” scenario, propagation fails (as it means that the file belongs to other site/service and it is unclear how to handle their propagation)

  • For “replace existing” scenario, EFT backs up the existing file and replaces it with up-to-date version from target server

The following parts of site are not propagated:

  • Admin ACLs

  • Site file system objects (physical files and folders)

  • Referenced external objects like Custom Command Executable, PowerShell Scripts, etc

  • SDConf.rec (RSA Securid config)

For site propagation to succeed, the specified target server's administrator credentials should correspond to the Server-level (to create new site) or Site-level administrator target server administrator (to replace existing site) of target server.

  • Site propagation fails if source or target server has SecretsModuleEncryptionKey Advanced Property defined

  • Source server records propagation progress to EFT.log via COMMON logger

  • Target server records propagation progress to EFT.log via COMMON logger

  • Target server registers propagation to ARM database as Admin Activity

  • Site.Created, for “create new” scenario

  • Site.Replaced, for “replace existing” scenario

  • Target server does not perform PCI audit when accepting site propagation

  • Site propagation is available via COM admin interface, ICISite::Propagate method

  • Site propagation is available via REST Admin interface; the request is POST to /Admin/v2/sites/<site-id> . The semantics of requests is RPC, and it is implemented based on JSON-RPC protocol (https://www.jsonrpc.org/specification) rather than in “standard” JSON:API model. The method name is “propagate.”

Success Case Example:

Failure Case Example: