QMS
Level 1
The Quarantine Management System (QMS) is a tool used to store messages that were blocked or are being tracked. They can be released or forwarded if needed, through the QMS Web Page, by the owner or administrator.
You can access the Quarantine Manager by clicking under Home Pages | Quarantine Manager
You can also access it by going to http://serverIP:49285.
You can quarantine any event desired.
You can also choose to never quarantine a certain event as well.
Global quarantine The Global quarantine message service acts exactly as it sounds; every single message passing through the mail system has a copy placed into the quarantine. This option overrules all other settings in the system, including forced deletion of virus infected messages; a copy will be placed in the quarantine.
You can either allow the users to view all globally quarantined email in their own QMS or make this available to the admin only.
There are various QMS settings that you can access through the GWAVA Management Web Page | Server/Interface Management | Server Management | Configure Server | QMS Configuration and Advanced QMS configuration.
The QMS role is an option to allow all QMS data to be stored in a central location when utilizing multiple GWAVA servers in a system. The ‘Master’ role sets QMS to have all quarantine data copied to that server from ‘Slave’ QMS servers. Slave QMS servers will contact the Master QMS and copy all quarantined data and messages to the master, storing all quarantined messages in a central location. This should not be changed unless multiple GWAVA servers exist in the system. GWAVA Quarantine system
The GWAVA Quarantine system has two different control levels for the interface: the general user interface, and the Administrator interface. When login credentials are passed to the Quarantine system, QMS, (Quarantine Management System), contacts the GWAVA management system for administrator accounts, and the GWIA for normal users. QMS uses a simple SMTP authentication to check for a valid user and password against the GWIA, so the same password used by system users is used to login to manage their personal quarantine. Admin users, setup in the GWAVA management console, should only use their username and password to login. Normal system users should use their full email address and GroupWise password to authenticate.
i.e.
admin
password
-or-
user@domain.com
password
Level 2
The quarantine management system module is called qms2. To unload the QMS only: For Linux type: rcgwavaman stop gwavaqms For Windows: from Services find GWAVA Quarantine, right click and choose stop To load the QMS only: For Linux type: rcgwavaman start gwavaqms For Windows: from Services find GWAVA Quarantine, right click and choose start To check the status of the QMS only: For Linux type: rcgwavaman start gwavaqms For Windows: from Services find GWAVA Quarantine, right click and choose start The QMS uses port 49285 - TCP Inbound (QMS message release service) The QMS directory is located: - on Linux: /opt/beginfinite/gwava/services/qms - on Windows: drive installed on/program files/gwava/gwava/services/qms The QMS directory is as follows: Data: Backup: Stores 7 days worth of backups of the qms_digest.db, qms_user.db, qms_data.db, and user_exception.db Db_setup: various xml files for db's Err: DB error files are stored here Scripts: qms scripts are stored here Storage: Mime files of Quarantined messages are stored here, in the structure of YR|Mnth|Day|Hr. Each message has a .msg and a .xml file. Four QMS db files: qms_data.db, qms_user.db, qms_digest.db, and user_exception.db. Forward: Queue for messages forwarded from within the QMS Http: Where QMS templates and Image files are stored Http-private: Where private templates are stored, such as a personal digest release button In_queue: Queue for messages that are quarantined Slave_in_queue: Queue for messages being quarantined if sharing a QMS with another server, which is the master server. Slave_out_queue: Outbound queue for messages being quarantined if sharing a QMS with another server, which is the master server. Temp: where temp files are stored Running.txt: QMS shutdown integrity check file. Do not delete this file. If you see issues that aren't explainable based on the settings, such as a digest not going out when there are clearing messages at that time frame for that user that should have gone out, then you can check the integrity of the qms_digest.db and the qms_user.db by doing the following: 1) Get a copy of the db that you want to check. They are located in ...gwava/services/qms/data. 2) Using SQL Expert Personal, load the db and click 'check'. 3) If it says 'ok' then this database is fine. If the digest and user db's are fine, but there is still some odd issues with the QMS (digest or missing messages) try running a rebuild by following this TID: [http://support.gwava.com/kb/?View=entry&EntryID=235 QMS Rebuild] If there are any other results other then 'ok', then the db needs to be fixed. You can repair the two smaller db's (doing a rebuild repairs the qms_data.db only). To repair a QMS db do the following: 1) Rename the db, for this example we'll rename it to qdigest.db and place in the same directory as the sqlite3.exe. 2) Open a command prompt and go into the directory that the above 2 files are located. 3) Type: sqlite3 qdigest.db .dump | sqlite3 qms_digest.db 4) A new qms_digest.db will have been created with no errors, you can then replace this with the one on the customer's server. The QMS logs can be found in ...gwava/services/logs/gwavaqms/support. Now its on to [http://training.gwava.com/index.php/GWAVA GWAVA]