FirstClass Gateways

FirstClass Gateways

Using gateways to connect school districts

Our school district's FirstClass server acts as the hub for a number of other school districts with which we replicate a number of conferences. The purpose is to share ideas and open discussions between like-minded people. However, making sure that all of the connecting districts follow proper procedures can be a bit tricky, so I have developed some standard procedures for connecting districts to follow.

In this discussion, I refer to "Hub" as the the central FirstClass server to which all spoke sites connect, and will speak as the Hub administrator. I refer to "Spoke" as the connecting site. In our real site setup, we have a number of different sites (or spokes) gatewaying to our own site.

This article discusses how we would connect a new Spoke site to our Hub site.

The following is the standard procedure that would be followed:

Creating the gateway

The first step is for both the Spoke and Hub administrators to create a simple working gateway to each other and to make sure that mail correctly passes between the two FirstClass systems.

Phase 1: Create and configure the gateway

This is how both the Spoke and Hub administrators should create and configure their gateway forms:

1 Open the Gateways folder on the administrator's Desktop.

2 Choose Admin > Add > Add Gateway Settings.

This will open a new gateway form.

3 Enter the gateway information on the Main tab.

For example, the Spoke administrator enters the Hub "Gateway name" (HubNet) and the Hub "Remote server serial number" (1234567) on the Main tab of their Gateway form. As the Hub administrator, I enter the Spoke "Gateway name" (SpokeNet) and the Spoke "Remote server serial number" (98765432) in these fields on the Hub system.

4 Enter the server address of the system to which you are connecting on the Connection tab.

For example, as the Hub administrator, I enter the Spoke address (fc.spokesystem.com) and the Spoke system administrator enters the Hub address (fc.HubSystem.com). The rest of the fields are specific to our individual site setups.

5 Both sites must have the same password in the "Password" field.

Both site administrators have to agree on a unique password. For example, both myself and the Spoke administrator agree on the password "password".

6 Close the form to save the changes, then reopen it.

7 Click the Directory button on the Gateway form.

8 Enter the same password from step 5 in the "Password" field and then save and close the Gateway Directory Information form.

9 Click the Scheduling tab on the Gateway Settings form.

10 Set the connection schedule for the gateways.

One system has to set the schedule. In our own setup, I let the Spoke administrator set their own schedule.

11 On the Multisite - Inbound tab, each site configures what works best for their system.

12 On the Multisite - Outbound tab, select "Export routes and gateways".

Both systems must have this option enabled to talk to each other.

If all the connecting systems (Spoke sites) are small, you can select "Export Directory names". If you do this, your users will have a larger than normal Directory to choose from when entering names in the "To" field.

Phase 2: Test the connection

The next step is to test to see if emails are getting through to both gatewayed systems. To do this, send an email to the Spoke administrator at Administrator,SpokeNet (where Spoke is replaced by the Spoke system's name) and have the Spoke administrator send an email back to me at Administrator,HubNet (where Hub was replaced with the name of the Hub gateway).

Once the emails are sent, you can wait for a scheduled connection or one of the administrators can force a connection by clicking this button on the Gateway form:

Choosing the conferences to share

Once the gateway is established and email is getting through, you have to decide which conferences to replicate, how to replicate them, and what permissions to set.

To synchronize items in a conference, the following must be true:

• the original name (not alias name) of the conference on both the local and the remote Desktops must be identical

• the conference must be at the root level of both gateway Desktops

• the local conference (the one on your system) must have permissions set so that the remote gateway is allowed to contribute.

You do not need to designate the Contributor permission specifically, you just have to make sure that if you set All Users to Disallowed as the last line of a permission list, that there is some provision above it for the Spoke system to be able to contribute.

The SpokeNet system can name the Hub specifically:

While the Hub system, which has many spokes, can use "Other Sites" to include all gateways.

Note that the Internet is a gateway, so you should put it first in the list to Disallow access to Internet postings.

Creating the conferences at the Spoke site

As administrator of the Hub site, I have found it helpful to keep track of all shareable conferences in a spreadsheet. I have created an Excel spreadsheet that contains the names and relevant information of each conference Spoke sites may want to replicate on their systems.

Use the spreadsheet as a guideline when building your conferences and the batch admin script to create your conferences.

To create your conference replication structure:

1 Create a conference called 'Gateway Conferences' on the administrator's Desktop.

2 Open the spreadsheet.

Click here to access the spreadsheet.

You can unprotect the sheet and change the names of the conferences to suit your needs. The yellow column is a calculated field that will change automatically based on the values in column A. There are two cells that you cannot change. They are the first two Admin Only conferences (Gateway Admins and Questionable Postings). These are required conferences for all sites connecting to our Hub server.

When the worksheet is protected all you will be able to modify is the "Select" column. The idea here is that you can select which conferences you want on your local system. To select a conference, click its corresponding cell in the "Select" column and choose Yes. Omit conferences by choosing No:

If you choose "No", the batch admin script in the yellow cell disappears.

3 Copy the yellow column to the clipboard (including empty cells, if present).

4 Log into the FirstClass server as the administrator.

5 Create a new message and address it to batch admin.

6 In the first line of the message body, type

7 Paste the contents of the clipboard into the message body below Reply.

The message will look something like this:

This will populate the Gateway Conferences conference on your administrator Desktop with the conferences you have chosen.

If you have correctly created the Gateway Conferences conference on your Desktop, batch admin will send back a blank reply (which is what you want). If the reply has errors, you have either not spelled the name of the conference correctly or you have one or more conferences with the same name.

Open the Gateway Conferences conference to see all of the conferences you just batched in. It will look something like this:

Setting conference permissions

The next step is to set the appropriate permissions for each conference. This has to be done before you replicate any information. All local conferences must make sure remote gateway is not denied contribution status on the Conference permissions form. Also, some of the conferences have other permissions that must be applied.

In the following examples, assume the following:

• HubNet refers to the Hub site's system

• DistrictNet is the global name that refers to our network of Hub and Spoke systems

• AdminGroup is either a group that has all of the gateway administrators on your system as members, or are the name(s) of individual(s) who are going to be monitoring the DistrictNet system.

We have four kinds of available conferences:

• Adult Conferences

• Open Conferences

• Student Conferences

The conferences in this category (Gateway Admins and Questionable Postings) should be monitored by members of AdminGroup.

The permissions for the Admin Only conferences should look something like this:

Adult Conferences

These conferences should be restricted to adults on your system (including all gateways).

You must have the ability to distinguish between adults and students on your system and set the permissions accordingly.

This should be your set of permissions for these conferences:

Open Conferences

These conferences should be open to everyone on your system (including all gateways). This is what your set of permissions for these conferences should look like:

There is one exception and that is the This_Day_In_History conference which is read only.

Student Conferences

These conferences should be open to everyone on your system. Establish a set of student moderators for these conferences. This should be your set of permissions for these conferences:

Creating conference policies and banners

Our current group of gateway administrators have agreed on some limitations to content that can be posted in some conferences. Good taste applies to all postings and if there are any violations, a notification must be sent to the Questionable Postings conference that indicates the location and subject of the objectionable messages.

Deleting a message from your local conference does not delete it from the other sites. Therefore, you must let other administrators know if you find an objectionable message, as it has likely been replicated across the network.

To help us communicate the limitations, I have created a series of banners for the top pane of conferences.

We use the wording below as banners in all of the gateway conferences. This lets our users know that the readership goes beyond the local system. This is advisable for all gateways as users tend to think that all messages are local and thus are not aware of the larger audience.

Some conferences have additional instructions in the banner:

Adding the banners as background images

To add the banner to the top pane, add the background images to the FC Resource Registry folder (you can also place them inside the Multi-Site Setup folder (both located on the administrator's Desktop)). Open each conference and chose View > Change View Properties to apply the image to the conference (see the Client help in online help for further information).

Aliasing conferences to the Spoke gateway Desktop

The following steps are performed at the Spoke site.

After creating your own conference policies and banners, alias the conferences to the gateway Desktop in preparation for replication. To do this, open the Gateway Conferences conference and select the objects you want to replicate. Then, choose Admin > Give Alias and enter the Hub gateway ID in the "User ID" field. This puts an alias of all conferences you selected onto the gateway Desktop.

Verify that the conferences are on the gateway Desktop by doing the following:

1 Open the Gateways folder.

2 Double-click the Hub gateway and click the Directory Information button.

3 Click the Desktop button.

This opens and displays all of the items on the local gateway Desktop. All of the regional conferences must also be on the remote gateway Desktop.

Aliasing the same conferences to the Hub (Remote) gateway Desktop

Once the conferences are aliased to the Spoke gateway Desktop, alias the same conferences to the Hub system's gateway Desktop. To log in as the gateway follow these steps:

1 Log into the Hub site using the Spoke server serial number as the User ID and the agreed-upon gateway password that is in the gateway form.

This displays the Spoke gateway Desktop on the Hub system.

2 Open the Self Serve conference and selected the DN Admins and Questionable Postings conferences.

3 Choose Collaborate > Add to Desktop.

This adds these two conferences to the root level of the remote gateway Desktop.

4 Open each of the subcontainers and repeat Step 3 for all of the conferences that you have on your local gateway.

At the next scheduled connection all unread content will begin to replicate.

If you want to force a replication of selected or all items to ensure both old (unflagged) and new (flagged) items are replicated:

1 Log into the Hub site as the gateway (as described above)

2 Open the conferences for which you wish to have old content replicated.

3 Select the messages you wish to replicate and choose Message > Mark as Unread.

This will indicate to the gateway that the items have not yet been read and they will be replicated at the next scheduled connection.