Cisco Cisco Email Security Appliance C160 Mode D'Emploi

Tip: it is not a good practice to have a group with the same name as the cluster, 
e.g. cluster London, group London.  If you are using site names for group names, 
it is not good practice to have a cluster name that refers to a location.

The correct method, as explained above, is to leave as many settings at the cluster 
level as possible. In most cases you should leave your primary site or main 
collection of machines in the Main_Group, and use groups for your additional 
sites. This is true even if you consider that both sites are “equal.”  Remember, CM 
has no primary/secondary or master/slave servers — all clustered machines are 
peers.

Tip: if you will be using extra groups you can easily prepare the groups before 
those extra machines are joined to the cluster.  

To configure this example cluster, log out of all GUIs on all machines before 
running 

clusterconfig

. Run 

clusterconfig

 on any one of the primary site 

machines. You will then join to this cluster only the other local and remote 
machines that need the maximum possible shared settings (allowing for the 
machine only-settings like IP address).  The 

clusterconfig

 command cannot be 

used to join a remote machine to the cluster — you must use the CLI on the remote 
machine and run 

clusterconfig

 (“join an existing cluster”).

In our example above we log in to lab1, run 

clusterconfig

 and create a cluster 

called CompanyName. We have only one machine with identical requirements, so 
we log in to lab2, and 

saveconfig

 the existing configuration (it will be drastically 

altered when it inherits most of lab1 settings.) On lab2 we can then use 

clusterconfig

 to join an existing cluster. Repeat if you have additional machines 

at this site needing similar policies and settings.

Run CONNSTATUS to confirm that DNS resolves correctly. As machines are 
joined to the cluster, the new machines inherit almost all of their settings from 
lab1 and their older settings are lost. If they are production machines you will 
need to anticipate if mail will still be processed using the new configuration 
instead of their previous configuration. If you remove them from the cluster, they 
will not revert to their old, private configs.

Next, we count the number of exceptional machines. If there is only one, it should 
receive a few extra machine level settings and you will not need to create an extra 
group for it. Join it to the cluster and begin copying settings down to the machine 
level. If this machine is an existing production machine you must back up the 
configuration and consider the changes to mail processing as above.