Existing Symantec Endpoint Protection (SEP) clients fail to communicate with their manager. New clients cannot register.
SEP shows a different "kcs" value (the hash of the encryption password set during the installation) in the conf.properties and the sylink.xml files published for its groups.
The following errors can be seen in a sylink.log of a client with Sylink logging enabled:
05/29 13:43:03.595  <EncodeHelper::DecryptUrl> Exception caught: Could not parse length parameter.
05/29 13:43:03.595  <CSyLink::Start> Decryption for the last server entry failed.
05/29 13:43:06.264  <SendRegistrationRequest:>http://<SEPM address>:<sepm port>
05/29 13:43:06.264  13:43:6=>Send HTTP REQUEST
05/29 13:43:06.304  13:43:6=>HTTP REQUEST sent
05/29 13:43:06.304  13:43:6=>QUERY return code
05/29 13:43:06.304  13:43:6=>QUERY return code completed
05/29 13:43:06.304  <SendRegistrationRequest:>SMS return=400
05/29 13:43:06.304  <ParseHTTPStatusCode:>400=>400 Bad Request
05/29 13:43:06.304  <SendRegistrationRequest:>ERR to query content length
05/29 13:43:06.304  <SendRegistrationRequest:>Content Lenght =>
05/29 13:43:06.304  HTTP returns status code=400
This problem happens after a SEPM is added as a new replication partner while specifying a recovery file with a different KCS value than the existing SEPM Site farm.
Once the replication is done as described above and has completed and SEPMs are restarted, SEPM A got an inconsistent status by showing two different "kcs" values in its conf.properties and in sylink.xml published for its groups. Replacing the sylink.xml for the already registered clients resolves the communication issue, however newly installed clients are unable to register and connect to SEPM A.
Reconfiguring an independent SEPM to become a replication partner is not compliant with Symantec's Best Practice for configuring a replication partner already during its installation.
The SEPM encryption password is configured when the SEPM is first installed as part of the Management Server Configuration Wizard. The client's encryption password is stored in its sylink.xml configuration file as the XML value "kcs", and will also be stored in the automatically created recovery file. If the value of "kcs" is not identical to the SEPM's encryption password, the SEP client will not be able to encrypt/decrypt communications to/from the SEPM.
When a new existing standalone SEPM is reconfigured as a replication partner, the Configuration Wizard will default to using the recovery file. This can lead to the kcs mismatch and communication problems described here.
SEPM 12.1.6 (RU6) and above no longer allow you to specify a recovery file when configuring a new replication partner.
To resolve KCS a conflict:
- Delete the newly added replication partner from the existing replication partner SEPM console.
- Re-run the Management Server Configuration Wizard (MSCW) on the existing replication partner SEPM and choose Reconfigure the management server and use a recovery file.
- Re-run the MSCW on the new replication SEPM and ensure Use a recovery file to restore communication with previously deployed clients is un-checked.
Any clients deployed from the new replication partner before making the above changes will need to have their communications settings reset either by dropping a sylink.xml file or pushing a communications package from the manager.