Cisco Cisco Email Security Appliance C170 Guia Do Utilizador

Group London:

Machine lab1.cable.nu (Serial #: 000F1FF7B3F0-CF2SX51)

...

However, this configuration tends to confuse many administrators, because they begin making changes 
to the London systems at the group level, and they stop using the Cluster level as the normal 
configuration level for basic settings.

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.

If there are two or more, as in our example, decide if those two will share any settings with each other 
that are not shared with the cluster. In that case, you will be creating one or more groups for them. 
Otherwise, you will make machine level settings for each, and do not need to have extra groups.

In our case we want to run 

clusterconfig

 from the CLI on any of the machines already in the cluster, 

and select ADDGROUP. We will do this twice, once for Paris and once for Rome.

Now you can begin using the GUI and CLI to build configuration settings for the cluster and for ALL 
the groups, even if the groups have no machines in them yet. You will only be able to create machine 
specific settings for machines after they have joined the cluster.