smaller reset larger        English         

Main Menu

All times are in GMT -8 (DST) :: The time is now 4:55 am.

Sub Menu

Category Details
Category Name
Category Created
Fri, 9th Mar 2007
Last Article Update
Mon, 12th Oct 2015
Category Actions


Knowledgebase Categories 

Backing Up CommuniGate Pro 


The CommuniGate Pro message store allows for “live” backups using any standard backup-restore program. The server does not have to be stopped to do a backup.

CommuniGate Pro will work with any back-up software appropriate to your operating system. CommuniGate Pro requires that no file locking mechanisms are used during the backup process. In the event that file locking is used, the system may be unintentionally brought down or account information corrupted (this is only a problem in the Microsoft Windows environment). Restored CommuniGate Pro files can be restored using the regular procedures employed by your backup-restore program.

All of the default BASE directory data in /var/CommuniGate (C:\CommuniGate Files on Windows) is critical, including the directories:

Settings/ Domains/ Accounts/ WebSkins/ Directory/ Queue/ Submitted/ SystemLogs/

The real messaging data is usually in the Accounts/ and Domains/ directories, as every user’s directory is located underneath those two areas. The configuration data in Settings/ and in the Accounts/ and Domains/ directories, so you could consider these the most important data locations.

If you have the capacity to backup all of /var/CommuniGate, this is what you should do.

CommuniGate Pro files can be restored using the regular procedures employed by your backup-restore program. Many site administrators choose to restore data to an account by creating a new mailbox called, for example, “Restored Mail” and putting the restored data there, allowing the user to move the mail back to its sorted folder location as desired. This method eliminates the potential delivery of new email to a user’s Inbox or mailboxes at the same moment in time when the administrator is restoring mail – this is a potential “race condition” which could cause the loss of new email. Therefore, CommuniGate Systems recommends the use of a Restore mailbox for restoring when the system is live. Upon creating a new mailbox in the user’s directory tree, the administrator may need to subscribe the user to the new mailbox using the CommuniGate CLI command “SETACCOUNTSUBSCRIPTION” or through the WebAdmin Interface. If restoring messages directly to existing mailboxes, the user’s file may need to be refreshed using the WebAdmin Interface “Current” button on each account, but as mentioned above, restoring to a Restore mailbox is the recommended approach.

Tape back-up, store to disc and other methods are all supported. One of key features in backups can be mirroring. Many storage systems support the ability to mirror the file system or directory structure to another device. Using this mirroring an “offline” system can be used to store “snapshots” of the live systems. From the offline system, backups to a tape device can be done without impacting the live environment. This means that backups of multiple terabytes of data can be done any time of the day or night. Recovery of the data can then be done by putting the “offline” system into production with the latest snapshot or do a restore from the offline storage system rather than restoring from a significantly slower tape device.

Using a strategy of weekly or monthly “full” backups as well as daily or weekly “incremental” backups will allow a measure of both efficiency and completeness of the backups. Full backups will require a longer backup duration, so should be run at times of least load. Incremental backups will be substantially faster, as only those files changed since the last backup will be stored.
View Full Article Add Comment

CGP Startup Parameters: Documented/Undocumented & 

There are two items that must be read to understand the manner in which CGP starts up at launch.


The first article can be found at This section primarily concerne standard startup parameters and explains what each one accomplishes.


The seceond is found at This covers a number of OS and tuning related options for the various supported OS's.


The main thing that one should gain from these articles is that while a number of these can be accomplished by editing files within the application directory or in the OS control panel, is that it is possible to create a file in the CGP Base Directory. By creating the, this means that you have a permanent file for the startup parameters as an upgrade to CGP destroys the modified application directory. This is highly recommended for any location running CGP Dynamic Clusers. This way the startup parameters are never affected by an upgrade.


There are also two undocumented, at this writing, startup parameters that have been needed after the release of 5.4.x


--TLSServerHelloExtensions NO

This one has been added as the workaround for problems accepting TLS connection requests from clients that used older versions og OpenSSL libraries and advertize support for some TLS extensions which are not really supported. Examples of this are financial institutions unable to send mail to your CGP server. Connection is made but TLS fails to negotiate. More on what the TLS Extensions are (and in turn what is disabled when you use the above parameter) can be found here:


--CalDAVAutoSched NO

This has been added as a workaround for the problem that some CallDAV clients have working with CGpro 5.4 that started to advertize the DAV "autosched" capability. Seeing it, the clients won't sent meeting requests when a new meeting is added to a calendar - expecting the server to do that. But the implementation seems to be incomplete and the server does not sent the invitation. With this option use for CGPro startup, the "autosched" capability is not advertized and the CalDAV clients submit invitation e-mails themselves.

View Full Article Add Comment

Installing CGP on Mac OS 10.11 (El Capitan) 

A new security feature in El Capitan called System Integrity Protection ( is preventing the current CGP installer from placing the application software in the /usr/sbin directory.

The upcoming 6.1.7 version of CommuniGate Pro will address this by installing the application software in the /usr/local directory instead.

If you can't wait for version 6.1.7, you can disable (use precaution) System Integrity Protection by rebooting OS X in Recovery Mode, launching Terminal, and issuing the following command:

csrutil disable; reboot

More here:

View Full Article Add Comment

Installing the (API Perl Module) 

First you need to make sure that Perl is installed. For that, please reference the following documentation for your platform:
Once Perl is properly installed, "installing" the CGP perl module ( should really just be a matter of downloading it (, and placing it in the directory where you'll be storing scripts. Or you can place the file into one of the @INC directories (i.e. the diretories where Perl will look for modules when a script is run). The list of @INC directories can be displayed by running the perl -V command.
Now you are ready to run some scripts. Some sample scripts can be found here:
View Full Article Add Comment

Where is the CommuniGate Pro software Installed on my system? 

CommuniGate Pro currently runs on over 30 different platforms (OS and chipset combinations). Given that diversity, the default location for where the software resides will vary depending on the chosen platform.

There are two directories that are created when CommuniGate Pro is installed. We call them the application and base directory respectively. The application directory is where the software is installed and the base directory is where all of the settings, accounts, mail, and other account information will reside. You will find the default location of these directories, along with other system modifications that occur at the time CommuniGate Pro is installed by looking at the page linked below:
View Full Article Add Comment