CommuniGate Pro
Version 5.1
Objects
 
 
 
Domains

Domains

CommuniGate Pro Server can serve Accounts in its Main Domain, and, optionally, in multiple Secondary Domains, each with its own set of user Accounts (and other objects such as Mailing Lists, Groups, and Forwarders).

Every Domain can have one or several aliases (alternative names). All Domain names and Domain Aliases should be unique, and they should be registered with the Domain Name System (DNS).

In many cases, a Domain should not have a separate set of user Accounts, but should rather be a domain name alias for an already existing CommuniGate Pro Domain. You may also want to serve some domain names using account mapping and/or Unified Domain-Wide Accounts.

In all these cases, you do not have to create a new CommuniGate Pro Domain to serve a domain name.

See the Mapping section for the details.

When a client application connects to your CommuniGate Pro Server, and specifies an account name, the Server has to detect in which Domain to look for that Account. See the Access section for the details.


Displaying the Domain List

Use the WebAdmin Interface to view the list of Domains served with your Server. Open the Domains page in the Users realm.
You should be connected as the Postmaster or any other Server Administrator with the
All Users access right to open the Users realm.

    Filter:
3 of 3 Domains (13172 Accounts) Domain Aliases (3 of 3)
Domain IP Address Accounts Open Hits Last Hit Refs  
client1.com 192.0.0.264524289121:29:17 14 Settings
client2.com  785345621:30:32 7 Settings
mycompany.com 192.0.0.11380891589021:30:29 35 Settings
mail.client1.comclient1.comSettings
mail.client1.comclient2.comSettings
webmail.client1.comclient1.comSettings

To select domains by name, type a string into the Filter field, and click the Display button: only the domains with names containing the specified string will be displayed.

Each entry in the domain list contains the Domain name, the assigned network address (if any), and the number of Accounts in the Domain. If the Domain is a shared Domain served by a Dynamic Cluster, the Domain name has the [+] prefix. If the Domain is a Directory-based Domain, its name is displayed with the [D] prefix.

A list entry also displays the number of currently opened domain accounts, the total number of times domain accounts have been opened (since the Server last restart), and the last time any domain account was opened.

Select the Show Aliases option to include Domain Aliases into the list. Each Domain Alias element contains the link to its "real" Domain object list and settings pages.

Click a domain name to view the Objects in that domain.

Click the word Settings in the last column to view and update the Domain Settings.


Creating a New Domain

Type a new Domain name into the field on the right side of the Create Domain button.


Created

Click the Create Domain button. When a new Domain is created, its name appears in the Domain List.

If this Server is a member of a Dynamic Cluster, the additional Create Dynamic Cluster Domain button appears. Click that button to create a Domain that will be served with all Cluster members. The Domain created using the Create Domain button are created as "local" Domains and are served with this Server only.


Specifying Domain Settings

The Main Domain and all Secondary Domains have domain-level settings.

To open the Domain Settings page in your browser, either click the Domain Settings link in the Domains List, or click the Domain Settings link on the Domain Object list page.

Account Log Level: Mailbox Log Level:

The Account Log option allows you to specify how the account-level operations (account open/close, password verifications, mailbox creating/removing, size updates, etc.) are recorded. Log records created for account-related events have the ACCOUNT tag.

The Mailbox Log option allows you to specify how the mailbox-level operations (message storing/removing, message status updating, etc.) are recorded. Log records created for mailbox-related events have the MAILBOX tag.

Most of Domain Settigs can be set to the default value. In this case the actual setting value is taken from the global, Server-wide Default Domain Settings.

When the Domain Settings are modified, click the Update button. The page should appear again, displaying the Updated marker.

You can click the Objects link to switch to the Domain Object List.


Specifying Default Domain Settings

A Domain setting can have the default value. In this case the actual setting value is taken from the server-wide Default Domain Settings. You can modify these Default values by clicking the Domain Defaults link on the Domains (Domain List) page.

The Default Domain Settings page resembles a regular Domain Settings page.

A Dynamic Cluster installation maintains separate server-wide Default Domain settings for all non-Shared (Local) Domains, and cluster-wide Default Domain settings for all Shared Domains. In the Cluster environment, the Default Domain Settings page displays links that allow you to switch between the Server-wide and Cluster-wide Default Settings.

Settings


Multihoming and Dedicated IP Addresses

You should read this chapter only if you plan to support multihoming, if your system is behind a firewall, or if you have a non-standard Domain Name System setup.

When the Server starts, it detects its own network address(es). Your Server system is "multihomed" if it has more than one network (IP) address.

If the Server system has several IP addresses, some of them can be assigned (dedicated) to secondary Domains. Accounts in such domains can be accessed using any POP, IMAP, or other client application without explicitly specifying the full account name.

The Assigned IP Addresses option allows you to assign network addresses to the main and secondary domains.

Assigned IP Addresses
[206.40.74.198]
All Available
This option can be selected for one Domain only, and it is the default setting for the Main Domain.
All Server's network addresses not assigned to other Domains are assigned to this Domain.
Manually Defined
This option is selected by default for all secondary Domains.
If you want to assign (dedicate) an IP address to this Domain, type the address into the text field on the right of the pop-up menu. You can specify several IP addresses, separating them with the comma (,) symbol.
Only the Server computer's own addresses are accepted, and all specified addresses should not be already assigned to any other CommuniGate Pro Domain.
If you select this option and leave the text field blank, the Domain will not have any IP addressed assigned to it. In this case, to access the Domain accounts, users should specify the full account name (account@domain) in their client application settings. See the Access section for the details.
by DNS A-Record
When this option is selected, the Server sends a request to the Domain Name System and tries to resolve the Domain name. If an A-Record for this CommuniGate Pro Domain is found in the Domain Name System, the addresses from that record are assigned to the Domain. The system checks that all addresses retrieved from the A-record belong to the Server computer and that these addresses have not been already assigned to any other Domain.
This setting is useful if you have several secondary Domains with dedicated IP addresses and you want to redistribute the Server addresses from time to time. Instead of reconfiguring both DNS and Server settings, you may reconfigure the DNS records only, and the Server will take the updated data from the DNS.
by DNS MX-Record
When this option is selected, the Server retrieves the highest-priority MX record (relay name) for this CommuniGate Pro Domain, and then processes addresses in the A-record for that relay name.

For each Domain in the Domain List, the assigned network (IP) addresses are displayed. This can be used to check the DNS and Server setup for systems with multihoming.

Because of setup errors or due to a non-standard network and DNS setup, the Server's own IP address(es) may be left unassigned to any of the Server domains. Open the General Settings page to see the list of the Server own IP addresses. The unassigned addresses are marked in red.

When a client application connects to the Server via an unassigned address and the full account name is not specified, the Server does not allow the user to log in.


Enabling Services

Each Domain has a set of settings that specify which CommuniGate Pro services can be used with the Domain Accounts:

Enabled Domain Services
Default Mail Relay Signal Mobile TLS POP IMAP
MAPI SIP XMPP WebMail XIMSS FTP ACAP
PWD LDAP RADIUS S/MIME WebCAL WebSite PBX
Mail
If this option is disabled, incoming E-mail Messages are not delivered to Domain Accounts. Incoming messages are suspended in the Local Delivery module queue, and they are rejected if this option is not re-enabled within the specified period of time. See the Local Delivery module settings for the details.
Relay
If this option is disabled, Domain users will not be able to use the Mobile Users Support features. This can be useful if you provide free WebMail Accounts in this Domain and you do not want spammers to use these Accounts to enable SMTP relaying.
Signal
If this option is disabled, incoming Signals are not delivered to Domain Accounts. Incoming Signals are rejected.
Mobile
If this option is disabled, Domain users will not be able to connect to their Accounts from Internet Addresses not included into the Client Addresses list. This can be useful if you provide free Accounts in this Domain and you want Domain users to connect to those Accounts only from the dial-up addresses your own site provides.
TLS
If this option is disabled, secure (SSL/TLS) access to Accounts in this Domain is disabled.
POP, IMAP, MAPI, PWD, XMPP, FTP, ACAP
If a protocol option is disabled, Accounts in this Domain cannot be opened using that protocol.
SIP
If this option is disabled, users of this Domain cannot use the SIP operations that require auhtentication.
WebMail
If this option is disabled, the Domain Accounts cannot be opened using the WebUser Interface, and the Domain mailing lists cannot be browsed.
XIMSS
If this option is disabled, the Domain Accounts cannot be opened using the XIMSS Interface,.
SMIME
If this option is disabled, Secure Mail (S/MIME) features implemented in the WebUser Interface are not availble for Accounts in this Domain.
LDAP
If this option is disabled, users of this Domain cannot autenticate themselves with the LDAP module ("BIND") using their account names.
RADIUS
If this option is disabled, users of this Domain cannot be authenitcated using the RADIUS module.
WebCal
If this option is disabled, users of this Domain cannot use the Calendaring functions of the WebUser Interface.
WebSite
If this option is disabled, HTTP and TFTP access to this Domain Account File Storage is disabled.
PBX
If this option is disabled, users of this Domain cannot use the PBX services.

Services can also be disabled for individual Domain Accounts.

A service is available for an Account only if that service is enabled for the Account itself AND for the Account Domain. Disabling a service in the Domain Settings disables that service for all Domain Accounts.
Note: This is different from disabling a service in the Domain Default Account Settings: disabling a service in the Default Account Settings disables that service only for those Domain Accounts that have the Enabled Services option set to default.


Domain Limits

The System Administrator can specify some limits on the resources available to the Domain users.

A Domain Administrator can see, but cannot modify these limits.

ResourcesLimitsUsage
Accounts: 390
Mailing Lists: 5
RPOP Accounts: 15
MAPI Connections: 37

Domain Aliases

Each CommuniGate Pro domain can have aliases (alternative names). If the domain client.dom has the mail.client.dom and www.client.dom aliases, E-mail and Signals directed to user@mail.client.dom and to user@www.client.dom will be routed to the user@client.dom account. Also, to access the user@client.dom account via POP, IMAP, XMPP, and other client applications the account names user@mail.client.dom and user@www.client.dom can be specified in the client settings.

This is especially useful for WebUser clients. Users specify the domain name in their browser URLs, and users of the client.dom domain tend to use www.client.dom in the browser URLs. You may want to register the www.client.dom domain with the DNS, assigning it the same IP address as the address assigned to the client.dom domain, and then you should create the www.client.dom alias for the client.dom domain.

Domain Aliases

You can modify existing aliases, add an alias by typing a new name in the empty field, and remove an alias by deleting it from its field. Use the Update button to update the list of domain aliases.

The Domain Aliases are stored in the DomainAliases database located in the Settings directory inside the CommuniGate Pro base directory.


Directory Integration

The System Administrator can specify if the domain accounts should be included into the Central Directory.

Directory Integration
Object Records:

This panel is not displayed for Directory-Based Domains, since those domains are always completely integrated with the Directory.

See the Directory Integration section for the details.


Server OS Integration

CommuniGate Pro Accounts may be "mapped" to the accounts (registered users) of the Server OS. See the Accounts section for more details.

Legacy (Unix) Mailer Compatibility

The CommuniGate Pro allows you to create Accounts with external INBOX mailboxes. These mailboxes are stored not inside the CommuniGate Pro base directory, but in the system file directory known to the legacy mailer applications.

If you have to support Local Mailer compatibility for all or some accounts in a domain, you should specify the External INBOX settings:

Server OS Integration
External INBOX location:
~
External INBOX locking used:
External INBOX location
This setting specifies where the external INBOX files should be located. For each Account that has an external INBOX, the Server substitutes the asterisk (*) symbol with the CommuniGate Pro Account name.
Consult with your OS manuals to see where your legacy mailers expect to find user mailboxes. On most Unix systems, the /var/mail/ directory is the correct location, but some systems may use /var/spool/mail/ or some other directory.
External INBOX locking used
This setting specifies the file locking method to use for updates synchronization.

See the Sharing section for the details.


Domain Security Settings

A Domain can have its own set of enabled Authentication methods. See the Security section for more details.

A Domain can have PKI settings (Private Keys and Certificates) enabling secure communications (TLS, Certiciate Authentication, S/MIME) with that Domain.
Use the Security link on the Domain Settings page to open the Domain Security settings.
See the PKI section for more details.

A Domain can have Kerberos keys enabling "secure single sign-on" for that Domain.
Use the Security link on the Domain Settings page to open the Domain Security settings.
See the Security section for more details.


Processing Unknown Names

Addresses used in E-mail messages, in client "login names", and in Signals can contain unknown names. If the Server cannot find an Object (an Account, a Mailing List, an Alias, a Group, or a Forwarder) with the specified name, the Domain Unknown Names settings are used.

Unknown Names
Consult External Authenticator: 
Mail to Unknown
postmaster@client1.com
Calls to Unknown:
pbx
Access to Unknown:
error
Consult External Authenticator
When an unknown name is supplied and this option is enabled, the CommuniGate Pro Server sends a command to the External Authentication Helper application. That application can check an external database (or any other data source) and optionally create a new object (an Account, an Alias, etc.) with the specified name. If the program returns a positive response, the Server makes one more attempt to find a domain object.
Mail to Unknown
This setting specifies what the Server should do when unknown account/object names are encountered in E-mail message addresses.
Rejected
The address is rejected; if the message is being received via SMTP, the address is not accepted, and if it was the only message recipient address, the message is not received at all.
Discarded
The address is routed to NULL. The message is considered "delivered" immediately (it is discarded).
Rerouted to:
the address is changed to the E-mail address specified in the text field, and the Router restarts trying to route this new address.
Note: you specify an E-mail address, not an account name there. So, if you specify Rerouted To: Postmaster for the client1.com domain, messages sent to unknown names will be routed to the Postmaster account in the Main Domain, not to the postmaster Account in that client1.com Secondary Domain. Specify postmaster@client1.com to direct those messages to the postmaster Account in the client1.com Domain.
Note: you can use the asterisk (*) symbol in the E-mail address field. This symbol will be replaced with the original (unknown) name.
Sample:
The domain client1.com Mail to Unknown Name option is set to
Rerouted to: Bad-*@support.company.com
A message comes addressed to jjones@client1.com, and the Account jjones does not exist in the client1.com Domain.
The message is rerouted to bad-jjones@support.company.com
Accepted and Bounced
The Router accepts E-mail addresses with unknown names, routing them to the Local Delivery module. When the message is enqueued into the Local Delivery module queue, the module fails to find the addressed account/object, the message is rejected, and an error report is sent back to the sender.
Calls to Unknown
This setting specifies what the Server should do when unknown account/object names are encountered in Signal addresses. This setting is set in the same way as the Mail to Unknown setting.
Access to Unknown
This setting specifies what the Server should do when unknown account/object names are encountered in Access operations. This setting is set in the same way as the Mail to Unknown setting.

Sending Mail To All Accounts in the Domain

The administrator can enable the special virtual list (address) "all" that can be used to send messages to all Accounts created in this Domain.

<all@company.com>
Mail to All is distributed for: 
Mail to All is sent to Forwarders: 

Messages sent to the <all@domainname> address are stored directly in the Account INBOX mailboxes, bypassing any Account Rules.

Messages sent to the <all@domainname> address are not stored in the Accounts that have the Accept Mail to All setting disabled.

Mail access to the <all@domainname> address can be restricted.

anybody
Any message sent to the <all@domainname> is distrbuted to all accounts in this Domain.
Clients
A message sent to the <all@domainname> address is distributed only if it has been received via SMTP from an Internet address included into the Client IP Addresses list, or if the message was received using one of the authenticated methods (WebUser Interface, XIMSS, via RPOP, via POP using the XTND XMIT method, etc.)
Authenticated Users
A message sent to the <all@domainname> address is distributed only if it has been received from a Server user (Account) using one of the trusted methods.
Authenticated Domain Users
A message sent to the <all@domainname> address is distributed only if it has been received (using one of the trusted methods) from an Account in this Domain or from any other Server Account that has the domain administration right for this domain.
Authenticated Administrator
A message sent to the <all@domainname> address is distributed only if it has been received (using one of the trusted methods) from a Server Account that has the domain administration rights for this domain.
nobody
The <all@domainname> address is disabled. In this case it is possible to create the real Account, Forwarder, Group, or Mailing List with the All name.

Messages to <all@domainname> can be sent to all Forwarder addresses, too:

Send to Forwarders:
When this option is enabled, a new message is composed. Its envelope contains the addresses from all Forwarder objects in this Domain. The message body is a copy of the message sent to the <all@domainname>.

Sending Mail To All Accounts in All Domains

If the administrator has enabled mail distribution to all Accounts in the Main Domain, a message can be sent to all Accounts in all Domains.

To send a message to all Accounts in all server Domains, it should be sent to the alldomains@main_domain_name address.

For each Domain, the message source is checked and the message is distributed to the Domain Accounts only if it passes that Domain "Mail to All" distribution checks.


WebUser Interface Settings

Each Domain has several WebUser Interface settings:
WebUser Interface
Mail Trailer:
Account Web Site Prefix:
~
Account Web Site Banner:
Mail Trailer Text
The text in this field is appended (optionally) to all messages the Domain users compose via the WebUser and MAPI Interfaces.
Site Prefix
This option allows you to change the URL prefix needed to access Account File Storage via HTTP. It can be set to an empty string, so URLs for a File Storage will look like http://domainName:port/accountName/.
See the HTTP module description for more details.
Web Banner Text
When the HTTP protocol is used to retrieve an HTML file from an Account File Storage in this Domain, this text is inserted into the beginning of the file HTML "body".

Enabling Auto-Signup

You can allow users to create Domain Accounts themselves, via the WebUser Interface, or by using XMPP, or XIMSS clients.
Accounts
Free Auto-Signup:

If the Auto Sign-up option is enabled, the Sign-up link appears on the domain Login Web page. This link allows new users to open the Sign-up page, where they can enter a new account name, the user real name, and the desired password.

If the Auto Sign-up option is enabled, the XIMSS and XMPP modules report their self-registration capabilities.

The Server checks that an Account with the specified name does not exist and creates a new Account. The Server uses the Account Template settings for the newly created Account, overriding its Password and Real Name settings with the data specified by the new user.


SMTP Options

The SMTP panel controls how E-mail messages are sent from and received for Accounts in this Domain.

SMTP
IP Address for SMTP Send:
Force SMTP AUTH for:
Check Recipient Account:
IP Address for SMTP Send
Use this setting tell the SMTP module to use a particular Local IP Address to send mail originated from this Domain. For example, if there is a risk that some of the Domain users can be involved in spamming activity, you may want to send all the Domain mail via an IP address dedicated to that Domain, so the other IP Addresses of your Server will not be blacklisted.

The available options include:

any
The SMTP module should not use any particular IP Address when sending messages originating from this Domain. The module allows the Server OS to select some Server Local IP Address for outgoing SMTP connections.
first
For all messages received for or generated in this Domain, the SMTP module should use the first IP Address from the set of IP Addresses assigned to this Domain.
Note: in a Cluster setup, the Server selects the first assigned IP address that is local for the Cluster member actually sending the message.
same
The SMTP module should try to use the same Local IP Address that was used to receive the message. If the message was received using the SMTP protocol or using the XTND XMIT extension of the POP3 protocol via a Server Local IP Address assigned to this Domain, the same Server Local IP Address will be used to send the message out (to relay it).
In all other cases, the first IP address assigned to the Domain (see above) will be used.
Note: this option should NOT be used if you have a firewall and some of the Server Local IP Addresses belong to an internal LAN: users can submit messages via internal LAN IP addresses, and the SMTP module will fail to send those messages to the Internet if it has to use an internal LAN IP address.
Note: in most cases, the First option (see above) provides better results.
Force SMTP AUTH for
If this option is enabled and the SMTP module receives a message Return-Path address that belongs to this Domain, the address (and the message itself) are rejected unless the client application user has been authenticated.
See the
SMTP Module section for the details.
Check Recipient Account
This option specifies if the SMTP Module should perform additional checks when processing the RCPT TO command targeting a local Account.
If this option is enabled, the module accepts the command only if:
  • the Account Mail Service is enabled, and
  • the Account Message Storage quota is not exceeded, and
  • the Account Incoming Flow control limits are not exceeded.

Domain Rules

Domains can have Automated Rules that are applied to all E-Mail Messages and all Signals being delivered to Accounts in those Domains. See the Rules section for more details.

Administrator Domain

Domains can be controlled by the Server Administrators and by the Domain Administrators - Accounts in the same Domain that are granted some Domain Adminstrator Access Rights. You may choose to grant administration rights for this Domain to Domain Administrators created in a different Domain. In this case the name of that other Domain should be entered into the Administrator Domain Name field:
Administrator Domain

If this field is not empty, the Domain Administrator Accounts created in this Domain and the Domain Administrator Accounts created in the specified Domain can be used to administer this Domain.

See the System Administrator section for more details.


Renaming Domains

If you want to rename a Secondary Domain, open its Domain Settings page, fill the New Domain Name field, and click the Rename Domain button.

If there is no other Domain with the same name as the specified new domain name, the Domain is renamed and its Domain Settings page should reappear on the screen under the new name.

You cannot rename a Domain when any of its Accounts is in use.


Removing Domains

If you want to remove a Secondary Domain, open its Domain Settings page, and click the Remove Domain button. The confirmation page should appear. If the Empty Domains Only option is selected, a Secondary Domain is removed only if there are no Accounts in it. Otherwise, all Domain Accounts are permanently removed, too.

If you confirm the action, the selected Domain, its settings, all its Accounts and other Objects will be permanently removed.

You cannot remove a Domain when any of its Accounts is in use.


Domain File Directories

The Main Domain data is stored in the Accounts file directory inside the CommuniGate Pro base directory.

The secondary Domains data is stored in the Domains file directory inside the base directory. For each secondary Domain, a directory with the Domain name is created in the Domains directory. All shared Domains in a Dynamic Cluster and stored as subdirectories of the SharedDomains directory.

If your server or cluster serves many (more than 3,000) Domains, you may want to create additional Domain Subdirectories inside the Domains and/or SharedDomains directory.

Each Domain directory contains data for all Domain Accounts.

When a domain contains many Accounts, Account Subdirectories inside the Domain directory can be used.

Domain Subdirectories

When a CommuniGate Pro system serves many Domains (more than 3,000), you may want to place Domain files directories into several subdirectories:

Domain subdirectories are directories inside the Domains or SharedDomains directory. A subdirectory name has the .sub file path extension (suffix).

Subdirectories can be nested.

Note: When the CommuniGate Pro Server starts, it scans the Domains directory and all its .sub subdirectories, and it collects the names and file paths of all Domains it finds there.
This feature allows the administrator to change the foldering method (see below) without stopping the Server and without relocating already created Domains. It also allows the system administrator to move Domains between subdirectories at any time when the CommuniGate Pro Server is stopped.

When a new Domain is being created (or when an existing Domain is being renamed), the Server composes a name for the subdirectory in which the Domain files should be created. The Domain Storage panel contains the settings that control how a subdirectory name is composed. Open the Domains page of the WebAdmin Interface, and follow the Domain Defaults link to open the page that contains the Domain Storage panel:

Domain Storage
Foldering Method:
Rename In Place:
Foldering Method
This option allows you to specify the subdirectory name construction method. The following methods are supported:
flat
This is the default method. All new Domains are placed into the Domains directory itself (or SharedDomains directory if a shared domain is being created or renamed in a Dynamic Cluster).
2 Letters 1 Level
The first two letters of the Domain name are used to form the name of the subdirectory, the Domain client1.com will be placed into the Domains/cl.sub/ subdirectory. If the Domain name has just one letter, that letter is used as the subdirectory name.
2 Letters 2 Levels
The first two letters of the Domain name are used to form the name of a nested subdirectory, the Domain client1.com will be placed into the Domains/c.sub/l.sub/ subdirectory. If the Domain name has just one letter, that letter is used as the subdirectory name.
Hashed 1 Level
A numeric hash function is applied to the Domain name, the result is used to form a subdirectory name: the Domain client1.com will be placed into the Domains/nu.sub/ subdirectory.
Hashed 2 Levels
A numeric hash function is applied to the Domain name, the result is used to form a nested subdirectory name: the Domain client1.com will be placed into the Domains/pj.sub/v.sub/ subdirectory.

Note: if you cannot store all Domains on one disk volume, you can copy some xx.sub directories to other volumes, and replace them with symbolic links.

Rename in Place
If this option is not enabled, and you rename a Domain, the CommuniGate Pro Server uses the currently set Foldering method to compose a new file path for the renamed Domain and moves the Domain data there. If you have replaced the xx.sub directories with symbolic links to directories on different disk volumes, such a rename operation may require moving data from one volume to a different one, and it will fail. If you enable this option, the CommuniGate Pro Server will move (rename) the renamed Domain data within the same directory, so the "cross-volume link" problem will be avoided.

Account Subdirectories in Large Domains

When a CommuniGate Pro Domain contains many Accounts (more than 10,000), you may want to place account files in several subdirectories:

Account subdirectories are directories inside the Domain directory. A subdirectory name has the .sub file path extension (suffix).

Subdirectories can be nested.

Note: When the CommuniGate Pro Server starts, it scans all domain directories and all their subdirectories, and it collects the names of all domain Accounts. This feature allows the system administrator to move accounts between subdirectories at any time when the server is stopped. It also allows you to change the foldering method (see below) without stopping the server and without relocating already created accounts.

For each Account, the CommuniGate Pro Server remembers the name of the subdirectory that contains the account files.

When a new Account is being created (or when an existing Account is being renamed), the Server composes a name for the subdirectory in which the Account files should be created.

Account Storage
Foldering Method:
Rename In Place:
Generate Index:
Foldering Method
This option allows you to specify the subdirectory name construction method. The following methods are supported:
flat
This is the default method. All new Accounts are placed into the domain directory itself.
2 Letters 1 Level
The first two letters of the Account name are used to form the name of the subdirectory, the Account jsmith will be placed into the domain/js.sub/ subdirectory. If the account name has just one letter, that letter is used as the subdirectory name.
2 Letters 2 Levels
The first two letters of the Account name are used to form the name of a nested subdirectory, the Account jsmith will be placed into the domain/j.sub/s.sub/ subdirectory. If the account name has just one letter, that letter is used as the subdirectory name.
Hashed 1 Level
A numeric hash function is applied to the Account name, the result is used to form a subdirectory name: the Account jsmith will be placed into the domain/pf.sub/ subdirectory.
Hashed 2 Levels
A numeric hash function is applied to the Account name, the result is used to form a nested subdirectory name: the Account jsmith will be placed into the domain/lu.sub/y.sub/ subdirectory.

Note: many systems process large Domains with account subdirectories, too. Every time an account is to be opened, those systems form the account subdirectory name using some built-in method. As a result, the built-in method cannot be changed "on the fly", and accounts cannot be moved between subdirectories. The CommuniGate Pro Server uses its subdirectory name forming methods only when a new Account is being created or when an Account is being renamed, and it always remembers in which subdirectory every Account is located. The Server does not have to form the subdirectory name every time an Account is to be opened. As a result, the CommuniGate Pro domain "foldering" methods can be changed at any moment, and the Accounts can be moved between the subdirectories when the server is not running.

Note: if you cannot store all Domain Accounts on one disk volume, you can copy some xx.sub directories to other volumes, and replace them with symbolic links.

Rename in Place
If this option is not enabled, and you rename an Account, the CommuniGate Pro Server uses the currently set Foldering method to compose a new file path for the renamed Account and moves the account data there. If you have replaced the xx.sub directories with symbolic links to directories on different disk volumes, such a rename operation may require moving data from one volume to a different one, and it will fail. If you enable this option, the CommuniGate Pro Server will move (rename) the renamed Account data within the same directory, so the "cross-volume link" problem will be avoided.
Generate Index
If this option is enabled, the CommuniGate Pro Server creates the Index.data file in the Domain file directory. This file contains the names of all Domain Accounts, the Account types, and the location of the Account files. When the Server starts and finds the Index.data file in the Domain directory, it reads that file instead of scanning the Domain file directory tree. On some file systems scanning a directory tree with 100,000 files can take up to 10 minutes.

Note: if you have stopped the Server and manually moved/removed some Domain Account directories, delete the Index.data file from the Domain directory before you start the Server again.

Note: if you want to keep only symbolic links in the Domain file directory, you can create the Index subdirectory inside the Domain directory (or an Index symbolic link to some other directory). If this subdirectory exists, the Server stores the Index.data file inside that subdirectory rather than in the Domain file directory itself.


CommuniGate® Pro Guide. Copyright © 1998-2007, Stalker Software, Inc.