Endpoint Protection

 View Only
  • 1.  14.2.4814.1101.105 clients rebooting unexpectedly

    Posted Dec 06, 2019 12:10 PM

    I've got a whole bunch of Windows Server 2012 systems, running SEP 14.2.4814.1101.105, "basic protection for servers" package.

    Some of them have rebooted unexpectedly, due to SEP:

    The process C:\Program Files (x86)\Symantec\Symantec Endpoint Protection\14.2.4814.1101.105\Bin\ccSvcHst.exe (SERVERNAME) has initiated the restart of computer SERVERNAME on behalf of user NT AUTHORITY\SYSTEM for the following reason: Legacy API shutdown
     Reason Code: 0x80070000
     Shutdown Type: restart
     Comment: 

    For most of the problem clients, this has only happened once that I'm aware of, either when the SEPM server was rebooted, or the SEP Master Service was restarted, e.g. for an upgrade to SEPM.  Some of those were several weeks back, and one was this morning. 

    For one problem client, this happens every single time the master service restarts or the SEPM server is rebooted - I can replicate at will by simply restarting the master service on the SEPM server or rebooting the SEPM server, then waiting a couple minutes for the SEP client to trigger a reboot on the problem client.

    My current plan is to do a full uninstall, reboot, run cleanwipe, reboot, and install the latest client package on the one really bad problem client, and seeing how things go.

    For the other clients, scheduling downtime for many of them is difficult, so I'm wondering if this is a known bug, if there are workarounds, or what.

    Thanks.



  • 2.  RE: 14.2.4814.1101.105 clients rebooting unexpectedly

    Posted Dec 06, 2019 12:54 PM

    Can't seem to edit the initial post, so adding on here.

    I've found a couple more clients that have, in the past, rebooted due to ccSvcHst version 14.2.4814.1101.105 and even back to 14.2.1031.0100.105.  These all correspond to the times when the SEPM server was rebooted for Windows updates - a couple of minutes later, the SEP client triggered a reboot on the protected servers.  We didn't pick up on it until now, because these were happening during a normal maintenence window, and everyone had just assumed it was a Windows update that triggered the reboot.