Important notes & current limitatons:

Requirements for shared database setup:

• The central remote PostgreSQL server (for shared database) could be utilized with a built-in (native) PostgreSQL database server installed with one of the MetaDefender Core instances in the network. Or using a dedicated existing PostgreSQL database server (version 12.3 or newer is recommended).

• Before setting up, make sure to follow steps at Open Connection On PostgreSQL Server so that all MetaDefender Core instances could connect to the central remote PostgreSQL server.

• All MetaDefender Core instances must be installed on the same Operating System (Windows / Linux).

• The first MetaDefender Core instance connects to the shared database must be ready first (license activated, users/groups/roles created, SSO is enabled if using) before setting up other MetaDefender Core instances to connect and use that shared database.

Do not support:

• Do not support to switch from shared database mode back to standalone database mode.

• Do not support to change instance_name of MetaDefender Core in shared database deployment model after installed.

• Do not support upgrade older MetaDefender Core with non-persistent mode to using the shared database mode.

• Do not support to upgrade multiple MetaDefender Core instances at once in shared database mode

  • Stop all Core instances' scanning service before performing the upgrade.

  • Upgrade each Core server one by one instead.

  • For each Core, when the upgrade finished, then you can start using that Core for scanning without waiting for the other Core instances’ upgrade to be done.

• Do not support Central Management use-case with shared DB mode (yet).

Engine update:

• If selected to command update engines from Folder source, all MetaDefender Core instances must be able to access to the configured update folder, and the option DELETE FILES AFTER IMPORT will be unchecked and prevented for modification.

Authentication:

• Single-Sign-On (SSO) authentication settings (if using) cannot be shared among MetaDefender Core instances because SSO requires an unique login URL for every different Core.

  • If an user is locked for login on a certain MetaDefender Core instance(e.g. exceeded the number of failed login times), that user is not prevented for logging in on any other instances.

  • If an user is locked for sign-in on a certain MetaDefender Core instance (e.g. exceeded the number of failed login times), if the admin releases lockout on that user on that MetaDefender Core instance, that user is still not able to login on other MetaDefender Core instances.

Sanitized / DLP / Quarantined location changed after MetaDefender Core install:

• Windows:

  • Shared storaged path will be stored in 3 strings under key global in registry: quarantinepath, dlppath, sanitizepath as below

  • 

  • You can set either 1, 2 or 3 different paths for 3 strings above (means that quarantined, DLP and sanitized files will be stored in same or different storages corresponding). In case shared storage is not set in installation, values of 3 strings above will be empty.

  • Restart MetaDefender Core service after changed.

• Linux:

  • Open file /etc/ometascan/ometascan.conf and set shared storage path for 3 keys quarantinepath, dlppath, sanitizepath under section [global]

  • Restart ometacan service after changed.