Benachrichtigungen erhalten wenn der Symantec Endpoint Protection Manager (SEPM) keine Virendefinitionen aktualisiert

Seit Jahren benutzen wir die Symantec Endpoint Protection in meiner Firma. Aktuell die Version 14.0.1.
Eigentlich macht das Ding was es soll. Aber… Es gibt einen Fall in dem im Werkzeug Koffer von Symantec kein Tool vorhanden ist das Problem zu lösen.

Was passiert?

Eigentlich möchte man ja von einem Antivirensystem nichts hören und sehen. Es soll funktionieren und das war es.
Ganz besonders in einer Firma in der 5, 10, 20 und mehr Clients vorhanden sind.
Der SEPM (Symantec Endpoint Protection Manager), benachrichtigt much brav wenn auf Stations nach mehreren Tagen noch alte Virendefinition sind, oder auch eine bestimme Anzahl von PCs erreicht wurden, die alte Virendefinitionen haben. Oft sind das bei uns Maschinen, die unterwegs sind, oder lange nicht eingeschaltet wurden.

Aber es gibt einen Fall in dem der SEPM vollkommen versagt: Wenn nämlich der SEPM selber keine neuen Virendefinitionen erhält. Warum auch immer!

Ich hatte in den letzten Jahren mehrfach den Fall, in denen der SEPM keine neuen Virendefinitionen von Symantec geladen hat. Die Gründe waren vielseitig. Mal hatte der SEPM kein Internet aufgrund eines Konfigurationsfehlers, mal startete der SEPM gar nicht nach einem Windows Update.
Aber in den meisten Fällen war der SEPM einfach nicht fähig, die neuen Signaturen zu laden obwohl er anzeigte, dass welche zum Download bereit stehen.

Der letzte Fall ist besonders nervig. Ich habe zwei Support-Cases zu dem Thema schon offen gehabt, aber die redlich bemühten Supporter haben dennoch nichts herausbekommen.
Nach jeweiligem Neustart des Dienstes oder des Servers, lief es fast immer wieder. Also hatte sich scheinbar nur irgendwas intern „verklemmt“!

Dieser Fall ist aber gefährlich. Man bekommt von der ganzen Sache nichts mit, bis eine bestimmte Anzahl von PCs nach ein paar Tagen eben alte Virendefinitionen haben. In der Einstellung bei uns sind das 10% der Maschinen nach 4 Tagen. Man kann das zwar herunter drücken, aber diese Warnungen nerven meistens nur ohne triftigen Grund.
Und man kann in diesem Fall nicht mal testweise einfach den SEPM neu starten.
Eigentlich will ich keine Meldung und das System soll erstmal selbst versuchen erkannte Problem zu lösen.
Vor allem habe ich keine Lust irgendjemanden zu beauftragen, der pro Tag einmal diese blöde Konsole startet und nachschaut was los ist. Über alles andere bekomme ich ja auch Emails.

Ich finde solch eine lange Latenz, in der es nicht bemerkt wird, dass die AV-Signaturen alt sind, einfach gefährlich.
Aber Bordmittel darüber zu warnen gibt es nicht!
Zudem trat dieser Fall ca alle 6-9 Wochen immer einmal wieder auf.
Und das nervt.

Also habe ich mich auf die Suche gemacht und habe für den SQL Server in dem unsere Daten gehalten werden zwei kleine Jobs geschrieben die nachfolgend beschreiben werden.
Diese Jobs laufen nun einige Monate und haben bereits mehrfach erfolgreich dieses Problem „selbsttätig“ behoben…

Job 1: Symantec Virus Signature Check

Dieser Job läuft jede Stunde einmal.
Der Code macht einfach folgendes.

  • Sollte es in den letzten 32 Stunden (siehe Wert für @delta) eine Änderungen in den Signaturen gegeben haben ist alles OK
  • Gab es kein Update der Signaturen dann werden zwei Schritte eingeleitet.
  • Es wird über den internen SQL Mail Dienst eine Warnung versendet an den Admin.
  • Danach wird ein weiterer Job gestartet mit dem Namen Symantec SEPM Restart.

Die 32 Stunden, sind ein Wert der sich aus Erfahrungswerten gebildet hat. In 98% aller Fälle werden Signaturen innerhalb von 24h aktualisiert. Aber es gibt eben ein paar Ausnahmen

Taucht die Email mehr als zweimal auf, muss ich wohl irgendwie aktiv werden und mal manuell kontrollieren.

DECLARE @delta INT
-- number of hours
SET @delta = 32 
DECLARE @d DATETIME 
DECLARE @t VARCHAR(MAX)
IF NOT EXISTS(SELECT * FROM PATTERN WHERE INSERTDATETIME>DATEADD(hh,-@delta,GETDATE()) AND PATTERN_TYPE='VIRUS_DEFS')
BEGIN
      SET @d = (SELECT TOP 1 INSERTDATETIME FROM PATTERN WHERE PATTERN_TYPE='VIRUS_DEFS' ORDER BY INSERTDATETIME DESC)
      SET @t = 'Hallo Admin!

Die letzten Antivirus-Signaturen wurden am ' + CONVERT(VARCHAR, @d, 120)+' aktualisiert!
Es wird versucht den SEPM Dienst neu zu starten!

Liebe Grüße Ihr
SQLServerAgent'
      EXEC msdb.dbo.sp_send_dbmail @profile_name='Administrator',
				   @recipients='administrator@mydomain.de',
				   @subject='Symantec Virus Definitionen sind nicht aktuell',
				   @body=@t
      PRINT 'Virus Signaturen sind veraltet! Letztes Update: ' + CONVERT(VARCHAR, @d, 120)
      EXEC msdb.dbo.sp_start_job @job_name='Symantec Restart'
      PRINT 'Restart SEPM server!!!'
    END
  ELSE
    BEGIN 
      SET @d = (SELECT TOP 1 INSERTDATETIME FROM PATTERN WHERE PATTERN_TYPE='VIRUS_DEFS' ORDER BY INSERTDATETIME DESC)
      PRINT 'Virus Signaturen sind OK! Letztes Update: ' + CONVERT(VARCHAR, @d, 120)
    END

Job 2: Symnatec Restart

Dieser Job wird nur durch den Job 1 gestartet und er ist äußerst trivial.
Führt einfach nur 2 Befehle aus, die den SEPM stoppen und anschließend neu starten.

NET STOP SEMSRV
NET START SEMSRV

PS: Traurig war, dass man durch den Support auch keine Hilfe bekam, nachdem ich solch einen Lösungsansatz vorschlug. Man wollte mir keine Infos über die Strukturen der Tabellen geben. Letzten Endes waren die Suchmaschinen so nett alle nötigen Informationen zu liefern, denn ich war nicht der einzige mit diesem Problem.

Kennwortabfrage bei der Deinstallation der Symantec Corporate Edition 10

Wir nutzen in der Firma seit Jahren die Symantec Corporate Edition. Bisher in der Version 10.

Bei der Umstellung auf die neue 11er Version musste ich auf den Clients die alte Software entfernen.
Bei den Rechnern mit einer zentralen Installation wusste ich natürlich das Kennwort für die Deinstallation, denn das wurde von mir eingerichtet und lag im Password Safe.
Allerdings wurden scheinbar auch einige Clients von anderen Admins von CD aus installiert. Hier war mir nun unklar, was für ein Deinstallations Kennwort verwendet wird.

Nach einigem Suchen im Netz bekam ich drei Wege heraus die Corporate Edition zu entfernen:

  • Das Standardkennwort lautet bei einer nicht verwalteten Installation symantec
  • Man kann die Abfrage des Kennwortes bei der Deinstallation aber auch verhindern, indem man den Registryschlüssel UseVPUninstallPassword in HKLM\Software\Intel\LANDesk\VirusProtect6\CurrentVersion\AdministrtatorOnly\Security von 1 auf 0 umsetzt.
  • Symantec selbst bietet auf der Homepage eine komplizierte Beschreibung für die manuelle Deinstallation.
  • Nicht versucht habe ich das Norton Removal Tool, dass es auch gibt.