Home
Administering IBM Traveler
Information on planning, installing, configuring, and administering IBM Traveler.
Planning for installation and configuration
There are many installation and configuration considerations you should review before installing the IBM Traveler server.
Clustering and failover
The key to any production environment is the enablement of redundancy to account for planned or unplanned outages.
Disaster recovery
There are several methodologies to employ with IBM Traveler to recover from a server crash or failure.

Administering IBM Traveler
Information on planning, installing, configuring, and administering IBM Traveler.
- Planning for installation and configuration
  There are many installation and configuration considerations you should review before installing the IBM Traveler server.
  - Choosing a deployment configuration
    The IBM Traveler server can be deployed using several different configurations.
  - Planning IBM Traveler on IBM® i
    There are several IBM® i operating system considerations to be aware of when planning the IBM Traveler server installation on IBM i.
  - Clustering and failover
    The key to any production environment is the enablement of redundancy to account for planned or unplanned outages.
    - High Availability (HA)
      IBM Traveler servers can be configured to use a shared enterprise database. This configuration is referred to as a High Availability (HA) pool.
    - Disaster recovery
      There are several methodologies to employ with IBM Traveler to recover from a server crash or failure.
    - Domino® mail clustering
      The IBM Traveler service detects mail file replicas by reading the replica entries in the IBM® Domino® cluster directory database (cldbdir.nsf) on the mail server of the user. This database must grant at least reader access to the IBM Traveler server or servers (in an HA pool). Otherwise, the IBM Traveler server never fails over the connection to an alternate server for mobile users if their primary Domino mail server is down.
  - Planning for device security
    This section provides information about each IBM Traveler security option and how they can be applied by device type. You can use this information to plan your security configuration for IBM Traveler on your devices.
  - Planning for migration
    Migration covers a number of scenarios.
  - Language support
    This section lists and provides information on all supported language for IBM Traveler.
  - Sync protocol support
    When data is synced between the server and device, it is done so utilizing a protocol which controls what the message content (the HTTP body) contains.
  - Capacity planning guidelines
    This section provides guidance on capacity planning for various deployment configurations of the IBM Traveler server. It also touches on best practices for monitoring capacity.
  - Estimating the space needed for the IBM Traveler database
    You can estimate how much space is needed for the IBM Traveler database before it is installed.
- Installing the IBM Traveler server
  The following topics describe options for installing and uninstalling the server:
- Configuring IBM Traveler server
  The IBM Traveler configuration settings are part of the Domino® server document. The first time that the IBM Traveler server is started, it performs any necessary configurations. You might want to perform additional configurations beyond the basics. The following topics describe additional configuration options.
- Administering IBM Traveler
  The IBM Traveler server component functions as a Domino® server add-in task and responds to Domino server console commands. Topics in this section describe common administrative tasks for administering a IBM Traveler server.

Disaster recovery

There are several methodologies to employ with IBM Traveler to recover from a server crash or failure.

Deploying a IBM Traveler High Availability (HA) pool inherently provides recovery from a server crash or hardware failure. In the event of a failure, device requests and mail monitoring is shifted to the remaining servers in the pool. For more information, refer to High Availability (HA).

Alternatively, it is also possible to set up multiple standalone IBM Traveler servers as potential disaster recovery servers for each other. Each server could have the same access to all the mail files for a user on remote servers. If a IBM Traveler server is not responsive, the user can manually reconfigure the device client settings to point to another IBM Traveler server. Alternatively this failover could be automated using a front end proxy (for example, IBM® Mobile Connect). After a device switches to a new server, the sync anchors no longer match between the server and device. The protocol initiates a sync refresh, where all of the data on the device is replaced by a fresh copy of the data from your mail database. Internally, the IBM Traveler server keeps track of each piece of data that is on a device. If a device switches to another server, then this history is lost due to the fact that these tracking databases are not on the network or shared between IBM Traveler servers. Likewise, switching back to the original server can also result in a sync refresh. This kind of configuration is useful in a disaster recovery scenario where High Availability is not required.

Have feedback?
Google Analytics is used to store comments and ratings. To provide a comment or rating for a topic, click Accept All Cookies or Allow All in Cookie Preferences in the footer of this page.