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 [5864] <EncodeHelper::DecryptUrl> Exception caught: Could not parse length parameter.
05/29 13:43:03.595 [5864] <CSyLink::Start> Decryption for the last server entry failed.
05/29 13:43:06.264 [2712] <SendRegistrationRequest:>http://<SEPM address>:<sepm port>
05/29 13:43:06.264 [2712] 13:43:6=>Send HTTP REQUEST
05/29 13:43:06.304 [2712] 13:43:6=>HTTP REQUEST sent
05/29 13:43:06.304 [2712] 13:43:6=>QUERY return code
05/29 13:43:06.304 [2712] 13:43:6=>QUERY return code completed
0
05/29 13:43:06.304 [2712] <SendRegistrationRequest:>SMS return=400
05/29 13:43:06.304 [2712] <ParseHTTPStatusCode:>400=>400 Bad Request
05/29 13:43:06.304 [2712] <SendRegistrationRequest:>ERR to query content length
05/29 13:43:06.304 [2712] <SendRegistrationRequest:>Content Lenght =>
05/29 13:43:06.304 [2712] 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.
The solution for this issue differs depending on the version of SEPM and which database is used.
For SEPM versions 12.1.6 and newer using a SQL database AND for SEPM versions 121.1.6 through 14.3 MP1 using the embedded database.
SEPM 12.1.6 (RU6) and above no longer allow you to specify a recovery file when configuring a new replication partner.
To resolve a KCS conflict:
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.
For SEPM versions 14.3 RU1 and newer using the Default SQL Server Express database.
To resolve a KCS conflict:
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.