Symantec Endpoint Protection (SEP) clients do not fail back to a Symantec Endpoint Protection Manager (SEPM) with higher priority
search cancel

Symantec Endpoint Protection (SEP) clients do not fail back to a Symantec Endpoint Protection Manager (SEPM) with higher priority


Article ID: 177570


Updated On:


Endpoint Protection


Why do my Symantec Endpoint Protection (SEP) clients not fail back to a higher priority server after a failover occurs and the conditions causing the failover have been resolved?

One or more Symantec Endpoint Protection (SEP) clients are configured with a Management Server list that provides for failover from one Symantec Endpoint Protection Manager (SEPM) to another.

  • One or more SEP clients fail over from a high priority SEPM to a low priority SEPM due to a communications disruption.
  • After the communications disruption, the SEP clients do not fail back over to the higher priority SEPM.



Starting with Symantec Endpoint Protection 11 MR4 MP1, the SEP client tracks the last SEPM it was able to successfully communicate with in a registry value. The client uses this registry value instead of the Management Server List to choose which SEPM to connect to. The SEP client will consult the Management Server List again for one of the following reasons: 1. The SEP client has maintained uninterrupted communications with the SEPM currently listed in its registry value 2. The SEP client loses connectivity with the SEPM currently listed in its registry value. After the SEP client consults its Management Server List and successfully connects to a different SEPM, the registry value is updated to reflect the new SEPM and the process begins again.


After 24 hours of uninterrupted communications with a failover SEPM, a SEP client will fail back to the higher priority SEPM if it is able to.

If your SEP clients are unable to maintain a connection to a single SEPM for 24 hours (due to sporadic network connectivity issues - ie laptops that are taken home by users), or you do not desire to utilize this caching behavior, a registry value can be added to disable this functionality.

To delete the cached "Last Server" value:

  1. Open the registry editor (regedit.exe) on the SEP client and browse to the following registry key:
    HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\SYLINK\Sylink
  2. Right-click the LastServer value in the right pane and choose Modify
  3. Delete the value in the Edit window and click OK
  4. Restart the SMC Service using the smc -stop command to stop the Service followed by the smc -start command to start the Service.
    The SEP client will re-evaluate the Management Server List and add the new server to the LastServer registry value.

To permanently disable "Last Server" caching behavior:
You can also disable "Last Server" behavior by adding the following registry value (DWORD) on the SEP client(s), and setting it to 0:

HKEY_LOCAL_MACHINE\Software\Symantec\Symantec Endpoint Protection\SMC\SYLINK\Sylink\UseLastServer.

During a failover event, if the UseLastServer registry value is set to 0, a SEP client will choose a server from the Management Server List starting with the priority "block" that the client last connected to. The default priority block is 1. After a random server is chosen, during subsequent failures the client will walk through the management server list in the order that they are specified. If the client cannot connect to any servers within the same priority block, a new random server is selected in the next priority block and the sequence repeats.

Technical Information

- If a client has never continuously connected to the lower priority SEPM for more than 24 hours (switching off daily for example), it will be stuck with the lower priority SEPM unless you modify the registry.
- The code change also has an effect on load balancing after a SEPM failure.