Name Change task replication

When you create a name change task, the task is saved in a file called stnamechange.nsf, and this file is replicated to all home HCL® Sametime Community Servers so that updates can be made to each server's vpuserinfo.nsf database. The file vpuserinfo.nsf is the Sametime user information database that contains contact lists and privacy lists.

Set up a Domino replication task to replicate stnamechange.nsf among all servers. By default, stnamechange.nsf is replicated to all servers in a cluster, but not between clusters. This step makes it unnecessary to add future tasks to each stnamechange.nsf database in the environment. When a new task is added, all servers get the new information as a result of the replication procedure.

Note that the All servers option on the name change page in the Sametime System Console does not work because of the procedure for replicating across all servers. If you create a name change task and select All servers, only the server you are logged on to contains the task--other servers do not. This is viewable in stnamechange.nsf through the Notes client. The correct procedure is to create the name change task on all the servers in the community.

If several Sametime Community Servers operate as a cluster, create a name change task on only one server in the cluster. The vpuserinfo.nsf database replicates in real time among the servers in the cluster. When the name change task changes the vpuserinfo.nsf database on one server, the changes are automatically replicated to the vpuserinfo.nsf databases on all other servers in the cluster. Declaring the task in one cluster can populate all the clusters because you set replica information for the stnamechange.nsf between all the clusters.

The examples that follow illustrate how you might run name change tasks in different Sametime Community Server deployments.

Sample deployment 1

In this example, the Sametime community has the following characteristics:

Three Sametime Community Servers are deployed.

None of the servers are clustered.

With this deployment, you must create and run the name change task three times--one on each server. Though you create the task only once, you run it three times, and the run can be scheduled automatically.

Sample deployment 2

In this example, the Sametime community has the following characteristics:

Eight Sametime Community Servers are deployed.

Three Sametime Community Servers operate as Community Services cluster 1.

Three Sametime Community Servers operate as Community Services cluster 2.

Two Sametime Community Servers operate as home Sametime Community Servers but are not part of a Community Services cluster.

With this deployment, you must run the name change task four times. You can schedule the tasks to run automatically on one Sametime Community Server in Community Services cluster 1, on one Sametime Community Server on Community Services cluster 2, and on each of the two Sametime Community Servers that operate as home Sametime Community Servers but are not part of a cluster.

Sample deployment 3

In this example, the Sametime community has the following characteristics:

  • Six Sametime Community Servers are deployed
  • Three Sametime Community Servers operate as a Community Services cluster
  • Two Sametime Community Servers operate as home Sametime Community Servers but are not part of a Community Services cluster
  • One Sametime server is not used as a home Sametime server and is not part of a Community Services cluster

    With this deployment, you must create the name change task three times. Create the name change task on one of the Sametime Community Servers in the Community Services cluster and on each of the two Sametime Community Servers that operate as home Sametime Community Servers but are not part of a cluster. You do not need to create the name change Task on the Sametime Community Server that is not part of a cluster.