History |
Connecting to other servers
Understanding gateways
A gateway is a bridge between your system and another device or system. FirstClass supports several types of gateways:
• server-to-server gateways
• outbound gateways
• inbound gateways.
Gateways are configured from the Gateways and Services folder on the administrator’s Desktop. There are a number of third-party gateways supporting other systems and hardware. This document explains how to configure a server-to-server gateway. Information on configuring other gateway types will be found in the documentation accompanying those products.
Server-to-server gateways
Server-to-server gateways connect multiple FirstClass servers and FirstClass servers with FirstClass add-on modules, like Internet Services and Voice Services. Using server-to-server gateways, you can set up a large, integrated mail and conferencing network supporting conference replication, Directory synchronization, and multi-hop delivery. Your FirstClass server has built-in server-to-server gateway software.
The main reason for setting up a server-to-server gateway is so users on one server can communicate with users on another. Although the users could connect to the remote server by having a user account on that remote server, it is much more efficient to have users always connect to their local server, and have the servers handle the message exchange. If your users have Internet access, sending messages directly to the receiver’s email address is the easiest option.
Creating a gateway
Before planning new gateways, service accounts and routes, make sure you know how all the servers in your FirstClass network interact with each other. We recommend that you prepare a map of your network.
To create a gateway:
1 Open the Gateways and Services folder on the administrator's Desktop.
2 Choose Admin > Add > Gateway Settings.
3 Configure the gateway using the Gateway Settings form.
To configure a gateway, you must first:
• know the server serial number of the remote server
• give your server serial number to the administrator of the remote server (this number is displayed on the Server tab of the System Profile)
• know the site name of the remote server
• give your site name to the administrator of the remote server (this is the name set on the Server tab of the System Profile)
• decide whether to use a specific password or have FirstClass generate a password for the gateways (both sites must use the same gateway password)
• decide what schedule you want to have for gateway connections
• decide how much information in your Directory you want to share with the remote site.
Setting the gateway password
FirstClass uses a password generator to automatically generate a secure password for the gateway. To use this feature, simply leave the password field blank. To change the password, simply clear the existing password field. A new password will be generated and the remote site will be automatically updated the next time FirstClass connects to it.
To create your own password:
1 Click Directory on the Gateway Settings form to open the Gateway Directory Information form.
2 Enter the gateway password in the appropriate field.
 NoteFirstClass will automatically update the remote site's password the next time it connects.
Testing the gateway
The simplest way to check your gateway setup is to log into the gateway account on both the local and remote servers.
To log into the remote server, use the serial number of your local server as the user ID. To log into the local server, use the serial number of the remote server as the user ID. In both cases, use the gateway password as the login password.
Once you are logged in, you can perform the following tasks:
• prevent one or more messages in the gateway mailbox from being transferred
To do so, remove the Unread flag by clicking the flag while pressing Option (Mac) or Ctrl (Windows).
• force a message to be resent
To do so, click to the right of the Mail icon while pressing Option/Ctrl. The Unread flag will appear beside the item.
• verify that the correct conferences are being replicated.
Forcing a manual gateway connection
You might want to force a manual gateway connection immediately after configuring the gateway, or during troubleshooting, to force conference replication.
1 Open the Gateways folder on the administrator's Desktop.
2 Open the gateway for which you want to force a connection.
3 Click Connect on Close.
4 Click OK to make the gateway log into the remote server.
About conference replication
In addition to allowing you to exchange private mail between servers, gateways also allow you to replicate conferences. This means that a complete copy of a conference with all its contents can be seen and used on both servers. Any messages posted to the conference on the local server are replicated in the conference on the remote server, and vice versa.
 NoteDeletions are not synchronized between replicated conferences. Only new and existing items are replicated. Therefore, if a message in a conference must be deleted on all servers, the administrator of the server where the message was deleted must contact the administrators of all systems where the replicated conference exists and tell them to also delete the message.
Conference replication requires coordination between the FirstClass administrators on all servers on which the conference is to be replicated.
Once conference replication has been set up, items in the local conference will be replicated to the remote conference the next time the gateway connects.
Remember the administrator of the remote server must also set up conference replication on the remote site for items in the conferences on the remote server to be replicated to your local conference.
Avoiding replication loops
A replication loop occurs when you replicate a conference to another server, which replicates it to another server, which replicates it back to your server.
Be careful you do not set up a replication loop. For example, you might set up the following replication scheme:
 In this example, an item posted in Tokyo is replicated to Boston, which replicates it to Stockholm, which replicates it back to Tokyo, which replicates it to Boston...
The FirstClass server detects loops in the item history. When it finds a loop, it reports a Type 1 replication error (both on the server console and in the log file), and breaks the loop. In the preceding example, the Tokyo server would report such an error when it receives the item from Stockholm.) When this occurs, contact the other sites participating in the conference to solve the problem. (For example, this could be done by removing the conference alias from the gateway connecting Tokyo and Stockholm.)
To avoid replication loops, we suggest that you prepare a diagram of your conference replication scheme. Look for servers that can replicate conferences over multiple paths, like Boston and Tokyo. These two servers can replicate conferences directly, or indirectly, through Stockholmp
About self–serve replication
If there are many conferences on your server, and several different servers in your network, you may find that the administrators of the other servers may not want or need to replicate all of your conferences. In this case, you can allow the other administrators to select only the conferences on your server that they are interested in. This is called self-serve replication.
Whenever you create new conferences or delete old ones, update your self-serve conference and keep the other administrators informed.
Controlling access to replicated conferences
One of the standard user groups is named Other Sites. This group contains all gateways and all users on remote servers. You can use this group to increase daily time limits for your gateways and you can also use it to prevent users on other servers from contributing to conferences on your server.
For example, Husky Planes Toronto and Husky Planes Boston have replicated the Sales Reports conference. Husky Planes Toronto’s FirstClass administrator does not want users on Husky Planes Boston to contribute directly to the Toronto conference. (Normally, they could do so by addressing mail to “Sales Reports, Husky Planes Toronto”.) The administrator wants Boston users to contribute to their local conference. Therefore, the Husky Planes Toronto administrator disallows access to the conference by the Other Sites user group.
Remember that conference replication involves a certain amount of communication between the administrators at each site. Permissions are not passed from one server to the other during conference replication. All messages in the conference at the remote site are replicated into your conference, no matter how you define your local conference permissions. Therefore, if you are concerned about submissions from users who are permitted on the remote conference, but are not permitted on your local conference, contact the other administrator to try to make the conference permissions comparable at both sites.
Setting up conference replication
1 Make sure the conference you want to replicate exists with the same name on both servers.
2 Choose Admin > Give Alias with the conference selected.
3 Type the gateway's user ID at the "User ID" field.
4 Click Give Alias.
NoteFor two-way conference replication, follow the steps both on your server and on the remote server.
Setting up self-serve replication
1 Open the General Conferences folder on the administrator's Desktop.
2 Choose File > New > New Conference.
3 Choose File > Properties (Windows) or Get Info (Mac) with the new conference selected.
4 Type the name you want for this conference (for example, Self-Serve) at "Name".
5 Select "Protected".
6 Click OK.
7 Choose Collaborate > Permissions with the conference still selected.
8 Enter Other Sites at "Who" and choose Contributor at "Access".
This allows gateways to access this conference.
9 Enter All Users at "Who" and accept the default Disallowed at "Access".
This prevents users from contributing to this conference.
10 Add the gateway name as a member.
11 Close the Permissions form.
12 Make the appropriate conferences available for replication.
Select the conference, choose Collaborate > Add to Desktop, drag the resulting link from the administrator's Desktop to the self-serve conference, then give a link to the self-serve conference to all gateways.
13 Notify the administrators of other servers to which your server will replicate.
Send them a message asking them to log in as the gateway account, then drag the links of any conferences they want to replicate from the self-serve conference to their gateway Desktop.
NoteWhenever you create new conferences or delete old ones, update your self-serve conference and keep other administrators informed of the changes.
Setting up multisite mail
Using the Multisite Mail feature of FirstClass, you can set up large distributed mail networks consisting of many servers. FirstClass automatically decides how to route mail from one site to another through all of the intermediate server-to-server gateways.
When a FirstClass server receives a piece of mail destined for another site, it first determines whether it has a gateway to that site. If it does, it delivers the mail to the gateway. If it has no gateway, it checks to see if it has a route to that site. A route is a pointer to the next gateway on the path to the destination. If it has a route, it forwards the mail to the gateway specified in the route.
You can only have a route if you have a gateway to another FirstClass server which in turn has a gateway or route to the server that is your final destination. Each intermediary gateway is called a hop. The complete set of hops required to deliver a piece of mail to the end-point of the route is called a path. To add a route, you must first obtain the serial number and site name of the final remote server. This can be obtained from the administrator of the intermediary gateway, or from the administrator of the server to which you are creating the route.
Let’s look at the Husky Planes Boston network:
 On a multisite mail network, users can address mail to routes, just as they can address mail to gateways. For example, a user at Husky Planes Toronto is sending mail to a user at Husky Planes Tokyo: The Husky Planes Toronto server delivers the message to the Husky Planes Boston gateway and Husky Planes Boston delivers the message to Husky Planes Tokyo.
You can also include remote names in your Directory. Remote names are Directory entries for users on remote servers. If you include remote names, users can address mail to the user’s name only — they don’t need to include the route.
You can add routes and remote names to your Directory manually, but this method is time-consuming and subject to error. Instead, you might prefer to use Directory synchronization to automate the sharing of Directories. Both methods are described in the following sections.
Using Directory synchronization to automate multisite mail
Use Directory synchronization to set up automatic multisite mail in a network. When you designate the users, routes and gateways on your server that you want to synchronize, and then enable synchronization, they are added to the Directories of all the other servers. Users and remote names are defined as remote names, and gateways and routes are defined as routes.
Directory synchronization uses FirstClass scripting. Each server’s Directory is exported from its source server and imported into the target server using FirstClass scripting commands.
Directory synchronization considerations
Consider the following factors before enabling synchronization on all the servers on your network:
• If your network is large, Directory synchronization can produce very large Directories, containing many thousands of names, making them more difficult to use.
• If your servers communicate over expensive connections, the cost of doing full synchronizations can be high.
• If your Directories are large (2,000 names or more), the Directory export process can slow down your server. Schedule exports for a time when server activity is low.
• If your synchronized Directory will be large (2,000 names or more), you must allocate more memory on your server. As a guideline, for each session add 10 KB of memory for every 1,000 names.
• If you want some of the benefits of synchronization, but you want to limit the size of the lists, you can perform site synchronization. This produces a smaller synchronization list because it does not include remote names.
Based on these considerations, you may decide that you don’t want to set up Directory synchronization on your network. You can still send mail to users at remote servers by adding and maintaining remote names and routes manually.
Types of Directory synchronization
You can schedule one of the following types of Directory synchronization:
Planning your network
If you’ve decided you want to use Directory synchronization, the next step is to plan your network. Design a propagation scheme for your network, like the one in the following illustration, and be careful not to create replication loops.
Here again is the Husky Planes network, this time with Directory synchronization enabled (shown as a “D” on each server).
 Note that even though the Stockholm and Boston servers have a direct gateway, the Directories are replicated through the Tokyo server to avoid replication loops.
Configuring Directory synchronization
1 Open the Multi-Site Setup folder on the administrator's Desktop.
2 Open Multi-Site Setup in the Multi-Site Setup folder.
3 Fill in the Multisite Setup form.
Forcing immediate Directory synchronization
1 Open the Gateways folder on the administrator's Desktop.
2 Open the gateway to the remote server.
3 Click Manual Sync on the Multisite tab.
4 Click Connect on Close to manually force the gateway connection.
Directory synchronization begins after the gateway has performed any other necessary tasks, such as message delivery and conference replication.
Adding routes and remote names manually
The previous section described how to set up automatic multisite mail on your FirstClass network using Directory synchronization. If you decide that you do not want to use site or Directory synchronization, you can still send mail to users at remote servers by adding and maintaining routes and remote names manually.
To add a route manually:
1 Choose Admin > Add > Route.
2 Fill in the Route form.
If you have gateways and routes to other FirstClass servers, and you do not wish to synchronize your Directory with the other site's Directory, but you want to add selected individuals from other sites to your Directory, add them manually as remote names.
Remote names can also be added for mail that is routed via the Internet gateway.
To add a remote name:
1 Choose Admin > Add > Remote Name.
2 Fill in the Remote Name form.
| ||||||||