You notice that the SEPM system log says it ran Liveupdate successfully, yet the signatures for Endpoint Protection clients do not update. You may also see that certain SYSLOG categories fail to export to SYSLOG, and that the SEPM no longer replicates.
All Version of Microsoft SQL, and Windows Server.
This can result from a hung Liveupdate content SQL query. This can occur when the Symantec Endpoint Protection Manager is low on resources and may fail to process data from SQL, or fail to terminate the content job.
You may see on the SQL side a long running job similar to the one below with an IP/FDQN of the Symantec Endpoint Protection Manager as the source of the query/job.
-------------------------------------------------------------------
(@P0 nvarchar(4000),@P1 varbinary(max),@P2 int,@P3 nvarchar(4000),@P4 bigint,@P5 nvarchar(4000),@P6 bigint,@P7 nvarchar(4000),@P8 nvarchar(4000),@P9 nvarchar(4000),@P10 bigint,@P11 tinyint,@P12 nvarchar(4000))UPDATE BASIC_METADATA SET CHECKSUM = @P0, CONTENT = @P1, DELETED = @P2, OWNER = @P3, TIME_STAMP = @P4, TYPE = @P5, USN = @P6, NAME = @P7, DESCRIPTION = @P8, REF_ID = @P9, LAST_MODIFY_TIME = @P10, DISABLED = @P11 WHERE ID = CONVERT(CHAR(32),@P12)
-------------------------------------------------------------------
Terminate the Job, then reboot the SEPM to clear any hung JVM processes that SEMSRV.EXE may have spawned after the hung query.
After reboot allow the Symantec Endpoint Protection Manager to recover for 30-60 minutes then run the Liveupdate session manually.
Under low resource conditions the Symantec Endpoint Protection Manager can hang JVM jobs spawned by the SEMSRV process. This can also occur in environments where the replication schedule it too aggressive and overlaps other jobs locking tables the Liveupdate process may need.
This can also occur when third party reporting apps improperly lock tables while reading data from the SEM5 database.