Newly installed SEP clients present a green dot in the client side, but don't register in the console.
Even if virus definitions are out of date the client status is green with nothing to report.
From ersecreg.log:08/24 19:38:26 [6888:4904] 4 Bad format.
08/24 19:38:26 [6888:4904] <IP Address>--FAILED
This problem happens when SEPMs use a different encryption password (KCS) for client registration than their clients. This is the result of reconfiguring a SEPM using a recovery file with a different KCS value than the one used at the time of the client install. In normal circumstances, all clients will have the same KCS value as their managers. All managers in the local site and any replication partner sites will share the same KCS value. If the KCS values on clients do not match the KCS value on their manager, they will not be able to decrypt the encrypted communications between themselves.
The best solution to this problem depends on the SEPM architecture and which SEPM the incorrect KCS value was introduced from. You must determine where the KCS value was initially changed, and revert the changed KCS value to the original value. If any clients have been updated with the new KCS value, they must be reverted as well by applying the appropriate sylink.xml communications file.
Determine the current client KCS value
Use this process to find the KCS value SEP clients in the environment expect. In a multi-SEPM/multi-site environment, perform this check on at least 1 SEP client connected to each SEPM.
Determine the current SEPM KCS values
This process must be followed on all SEPMs in the local site, and any replication partner sites. The SEPM stores the KCS value in two locations. One location is used by the SEPM client registration module (secreg.dll), the other is used by the SEPM client communications module (secars.dll).
Compare KCS values
Compare the KCS values on both the sylink.xml and conf.properties files of the SEPM(s) to the client(s). The steps to fix the mismatch will depend on where the KCS value mismatch was introduced, and the number of SEPMs and SEPM sites in the environment.
single SEPM | The KCS values for both the sylink.xml and conf.properties modules on the SEPM should should match, but the SEP clients will have a different value. You will need to restore the original KCS value to the SEPM |
multi-SEPM, single site | The sylink.xml and conf.properties values should only match on 1 SEPM. You will need to restore the original KCS value to this SEPM. The SECREG value on the other SEPM(s) in the site will be the original KCS value for the site. |
multi-site |
The sylink.xml and conf.properties values should only match on 1 SEPM. You will need to restore the original KCS value to this SEPM. Note: depending on replication schedules and whether or not replication is successful between all sites, some SEPMs may retain the original KCS value in both locations. In this case, you must restore the original KCS value to the SEPM with matching KCS values for sylink.xml and SECREG that do not match the KCS value in the client's sylink. |
Revert the KCS value
Once you've determined which KCS value needs to be restored, and to which SEPM, use the following process to find the correct recovery file containing this KCS value and use the Management Server Configuration Wizard (MSCW) to reconfigure the SEPM with the correct KCS value.