This article describes the offline behavior when a Primary or Secondary PGP Encryption Server becomes unavailable.

 

For information on what the PGP Encryption Desktop client (Symantec Encryption Desktiop) does if the PGP server goes offline, see the following article:

153217 - PGP Encryption Desktop Offline Behavior with the PGP Encryption Server

If a PGP server is unavailable for a time, there are critical features that may not be available.  This risk can be reduced by using Load Balancing so that if one PGP servers goes down, the load balancer will redirect the PGP Encryption Desktop client to the other server that is still online.  For more information on this topic, see the following articles:

156803 - Using DNS Round Robin and Load Balancers, Front-End Security Applications and Reverse Proxies with Symantec Encryption Management Server

180244 - HOW TO: Download Encryption Desktop Client Installers in Symantec Encryption Management Server

When you have two or more PGP Encryption Servers operating in your organization, you can configure them to synchronize with each other; this arrangement is called a cluster.

In a cluster, one of the PGP Encryption Servers is designated as the Primary server for the cluster, which we call the "Sponsor"; all other cluster members are designated as "Cluster Nodes".  There really isn't the idea of a "Secondary" server, because really, each of the PGP Encryption Servers can have all the same data, and perform all the same actions, if you configure them to do so.  The additional cluster nodes in the "Cluster" synchronize their users, keys, managed domains, and policies with the other cluster nodes. Cached keys found in the mail flow are also replicated across the cluster.

The benefits of clustering include lower overhead (spreading the system load between the PGP Encryption Servers in the cluster means greater throughput) and the ability for email services to continue working even if one of the servers in the cluster goes down.

"Primary" Server VS "Sponsor" Server

The following text describes the behavior of a Primary server when the server becomes unavailable.  There is actually no difference between a Primary and Secondary servers unless you specify.  As mentioned above, when a PGP server is in a cluster, they all act as a "Primary", and it all depends on which services the PGP Server is hosting. If one server does not host all services, then you may consider that server to be your "Primary", although this nomenclature does not align exactly with the PGP Server because once the server enters a cluster, it has the capability to do everything another server has in every way and it is up to you to customize the services available. 

If you do have all services enabled on all PGP Servers, then they are all considered "Primary" servers or just "cluster nodes".  When a cluster node in a PGP Server cluster is unavailable or disconnected, the synchronization of users, keys, managed domains, and policies will not occur with other cluster nodes in the cluster. A cluster server cannot do everything the other server did if the services were not previously enabled and if all data, such as Web Email Protection were replicated across the clusters.   For example, in "DMZ Mode", you can choose not to replicate PGP Private keys.  If the server that has private keys goes down, this will drastically change the landscape for availability so special consideration should be made.
 

• When High Availability Mode is not enabled, the PGP Web Email Protection mailboxes on the server are unavailable and messages to those mailboxes are queued by Secondary cluster server members.
  (Check under the Web Email Protection Service and make sure "ALL" is configured to replicate all data.  Just make sure each of the nodes has plenty of hard drive space.  For more information on cluster best practices, see the following KB:
  
  154069 - Clustering Best Practices for the PGP Encryption Server
  
  
• Even though one of the cluster nodes may be unavailable, any PGP Web Email Protection mailboxes on Secondary servers will continue to be available if the "All" data was enabled on all nodes was previously enabled, and if the WEP service is enabled as mentioned above.  It is recommended to host ALL mail on all nodes for the Web Email Protection service and enable this service on all nodes for the best redundancy.
• Additional cluster nodes can still process some mail and enforce policy for existing and new internal users and existing external users.
• Additional cluster nodes cannot create new external users while the Primary server is unavailable unless they are specified to do so and designated as such.
• It all depends on if Private Keys are allowed to be hosted on the PGP server and this relates only to "DMZ" mode. 
  
  

Cluster Nodes

The following text describes the behavior of a cluster node when the server becomes unavailable.  

Data on unavailable servers will not replicate to other nodes in the cluster ring.  It is important to bring the node back online as soon as possible as this can cause further complications.
In other words, if a cluster node is down, do not rely on the cluster to continue to function if it is still in the cluster.  Reach out to Symantec Encryption Support if you are unable to get the cluster working again quickly.
It is highly discouraged to "remove/break" cluster members from the cluster.  Instead, reach out to Support for guidance. 

Once a cluster member becomes available again, a resynchronizing of data should occur and depending on how long the cluster member was down, could take several hours or even days, particularly if PGP Web Messenger is in High Availability Mode. 

• Each cluster node in the cluster continue to process mail and enforce policy for all internal and external users.
• When using Home Server mode on a cluster member, Web Messenger mailboxes will be unavailable. Messages to those mailboxes are queued by other cluster members.
  This is why it is not recommended to operate in home server mode--instead, use High Availability when possible. 
  
  

 If you need more information on what happens with the PGP Desktop client if the PGP server goes down or cannot be reached, see the following article:

153217 - Symantec Encryption Desktop Offline Behavior (PGP Desktop)

154069 - Best Practices: Environmental Requirements for PGP Encryption Server clustering (Symantec Encryption Management Server)

153721 - Creating a Cluster with Symantec Encryption Management Server (PGP Server)

153412 - Troubleshooting: PGP Server Clustering (Symantec Encryption Management Server)