Supporting multiple HCL Domino® domains

Typically, the HCL Traveler server deploys in the same Domino® domain as production mail servers. However, there are a number of reasons why you may want to separate your HCL Traveler server domain and your production mail server domains.

• If you want to keep the HCL Traveler server's directory (names.nsf) separate from production to prevent design changes from a higher level directory from synchronizing to a lower level directory server. In this environment, the directories would not sync unless it was explicitly enabled.
• All HCL Traveler servers in an HA pool must be in the same domain.
• To minimize the amount of data from the production servers that is accessible from the HCL Traveler server.

There are several items you must consider to make this possible. This checklist applies to any HCL Traveler installation. However, when installing in the same Domino® domain, many of these items typically work without any additional configuration.

• The HCL Traveler server must be able to physically connect to mail servers in the other domains. Use the Domino server trace command on the HCL Traveler server to verify that a physical connection can be made between the servers. For example, from within the Domino administrator console, use the command trace test_server/org1, where test_server and org1 are the actual identifiers of the mail server.
• The server ID file used by the HCL Traveler server must be cross-certified with any other Domino® domains that the HCL Traveler server needs a connection to.
• The remote mail servers must grant server access to the HCL Traveler server. You can verify this using the Domino® Administrator client. On the remote mail server, open the server configuration document, click the Security tab, and verify that this server is not restricted in the Server Access section.
• The HCL Traveler service queries the Domino® directory service whenever mobile users register with or connect to the HCL Traveler server. The Domino® directory must return the home mail server and the mail file path name for each user that registers with the HCL Traveler server. If the HCL Traveler server is in the same domain as the mail users, then typically the local names.nsf is already populated with person records for each user and this information is available by default. However, if the users are in other domains, then you must either configure Domino® directory assistance to find these other users or otherwise ensure that their person records are available in the local names.nsf.
• The HCL Traveler service queries the cluster database on the user's home mail server to find other mail servers and mail file paths that can be used for each user. Without access to cldbdir.nsf, the HCL Traveler service will only use the user's home mail server and mail file path.
• Historically, the HCL Traveler service sends mail and meeting notices using the mail.box files on the users' mail servers. Without access to the mail.box files on the users' mail servers, no mails or meeting notices will be deliverable. Starting with Traveler server 11.0.0 the Traveler service will switch Apple iOS and iPadOS devices to use the Exchange ActiveSync 16.1 (EAS16.1) protocol level.
  Note: A side effect of the server support for EAS 16.1 is that meeting notices from the Apple calendar application on these devices are sent using the Traveler server's mail.box. Routing failures can occur if the Traveler server is not configured to route mail to and from the mail servers. Meeting notices from the HCL Verse client on Apple devices are not impacted as these notices are still routed via the mail server mail.box. To avoid routing these notices through the HCL Traveler server, the notes.ini setting NTS_AS_SEND_NOTICES_FROM_MAIL_SERVER can be set to True to route the notices via the mail.box of the user's mail server. See Notes.ini settings for additional details.
• If you plan on implementing mobile security policies, use HCL Traveler default settings to define security policies. See Default device preferences and security settings for more information. Use these settings instead of HCL Traveler settings that are part of the Domino® admin policy setup. Otherwise you must define the HCL Traveler settings separately in every different Domino® domain for them to work correctly. If you are using HCL Traveler default settings, then these settings and security policies apply to any user that connects to the HCL Traveler server regardless of the Domino® domain that the user belongs to. For more information, see Assigning preferences and security settings to devices.
• If your Traveler version is 11.0.1 or later and the HCL Domino server on which Traveler is running is Domino 11.0.0 or later, you can set Domino config parameter IDV_ENABLE_CROSS_DOMAIN=1 in the notes.ini file on the Traveler server to allow the ID vault lookup even when the HCL Traveler server is in a different Domino domain than the user's mail server.

set config NTS_TRAVELER_AS_LOOKUP_SERVER=true

This will force all lookups to run against the local directory, which will then use Domino® Directory assistance if it is configured and needed to resolve a name.