alexcad

Kaspersky Security Center 13.0.0.11247 wurde am 29.03.2021 veröffentlicht. Infos und Download: https://support.kaspersky.com/de/ksc13 Neuerungen: https://support.kaspersky.com/KSC/13/de-DE/12521.htm Bekannte Einschränkungen: https://support.kaspersky.com/KSC/13/de-DE/211205.htm Systemanforderungen https://support.kaspersky.com/KSC/13/de-DE/96255.htm Wichtig - mit SQL 2019 muss folgender Hinweis aus dem Handbuch beachtet werden: https://support.kaspersky.com/KSC/13/de-DE/92235.htm Grüße Alex

Hallo Antrox, da hast du recht - das wurde schon ein paar mal hier im Forum diskutiert, z. B. hier LinkVielen Dank für die Lösung. Grüße Alex

Problem bei “Übersprungene Aufgaben starten” ist oft: Seit Version 10 ist beim Dienst des Netzwerkagenten “Automatisch (verzögerter Start)” als Starttyp vorgegeben. Somit schlagen z. B. Update-Aufgaben fehl, die nachgeholt werden sollen. Die Update-Aufgabe startet mit dem Anwendungsstart der KES, der Netzwerkagent ist aber noch nicht gestartet. Hier behelfe ich mir mit zwei Update-Aufgaben: Eine plane ich mit Intervall, die andere binde ich an den Anwendungsstart mit einer Verzögerung, damit der Netzwerkagent Zeit hat zu starten: Bei Installationsaufgaben besteht dieses Problem eher selten, da hier die Aufgabe oft während der Offline-Zeit des Clients erstellt und daher noch nicht übernommen wurde. Erst wenn der Client hochfährt und der Agent sich beim KSC meldet wird die Aufgabe übertragen und dann nachgeholt - wichtig ist eben, dass der Netzwerkagent bereits gestartet ist. Grüße ​​​​​​​Alex

Kann es sein, dass in der untergeordneten Richtlinie das Schloss auch offen ist und daher die Einstellungen nicht auf dem Client angewendet werden? Um das mit dem Schloss nochmal auszuführen: Bei der ersten Übernahme der Richtlinie werden alle Einstellungen vom Client übernommen, egal ob Schloss offen oder zu. Anschließend durchgeführte Änderungen werden nur auf dem Client angewendet, wenn die Einstellung verbindlich, also Schloss zu ist.Bedeutet: Irgendwo muss das Schloss bei jeder Einstellung in den Richtlinien zu sein. Wenn du mit über- und untergeordneten Richtlinien arbeitest, muss eine Einstellung, die in der übergeordneten Richtlinie offen ist, entsprechend in der untergeordneten Richtlinie (abweichend) konfiguriert und dann hier verbindlich gesetzt werden (Schloss zu). Ob und welche Einstellungen auf dem Client angewendet werden kannst du auf dem Client über die GUI herausfinden. Entsprechend muss hier auch alles ausgegraut sein. Und nochmal der Hinweis: Wenn du Ausnahmen sowohl in der übergeordneten, als auch in der untergeordneten Richtlinie ergänzend konfigurieren möchtest muss: in der übergeordneten Richtlinien das Schloss offen sein. in der untergeordneten Richtlinie der Haken bei “Bei Vererbung Werte zusammenführen” gesetzt und das Schloss zu sein.Noch ein Punkt: Die Ausnahme im zweiten Screenshot enthält keine ausführbare Datei. Müsste eigentlich so aussehen: Grüße Alex

Hallo Robert, zu deinen Fragen: 1.) Verstehe ich nicht ganz. Oder um die Frage zurück zugeben: Welche alternative Ordnerstruktur zur Baumstruktur wäre für dich denkbar bzw. wünschenswert? 2.) An den ausgegrauten Menüs ist erkennbar, das du in der übergeordneten Richtlinie die Schlösser zu hast. Damit sind diese Einstellungen verbindlich und können weder in einer untergeordneten Richtlinien noch auf dem Client geändert werden. Wenn du also einzelne Punkte in einer untergeordneten Richtlinie abweichend konfigurieren möchtest musst du entweder das Schloss in der Masterrichtlinie öffnen oder die Vererbung unterbrechen (auch das ist möglich). Generell würde ich von beiden Möglichkeiten eher abraten - das erhöht den administrativen Aufwand und das Risiko, dass Einstellungen nicht wie gewünscht bei den Systemen ankommen. Oft gibt es keinen konkreten Differenzierungsbedarf und der lässt sich in der Regel mit Richtlinienprofilen besser bedienen. Im Fall der Ausnahmen wäre eine untergeordnete Richtlinie noch einigermaßen sinnvoll, da sich hier inzwischen die geerbten Ausnahmen zusammenführen lassen - die Einstellungen der untergeordneten Richtline ergänzen die Ausnahmen dann und ersetzen sie nicht mehr, wie früher. 3.) Ordner müssen mit einem Backslash am Ende eingegeben werden, sonst wird der Wert als Dateiname interpretiert. Grüße Alex

Seltsam - ich schau danach. OK, war als SPAM gewertet, warum auch immer.

Hallo Dominik, eigentlich ist es ausreichend den neuen Schlüssel in der Lizenzverwaltung hinzuzufügen und den Haken bei “Automatisch verteilen” zu setzen. Wenn du den Advanced-Schlüssel manuell über die Aufgabe verteilen möchtest, darfst du den Haken bei “Schlüssel als Reserveschlüssel hinzufügen” nicht setzen. Kontrolliere das nochmal in der fertigen Aufgabe - ich sehe das immer wieder, dass der Haken irgendwie wieder reinrutscht. Bitte denke auch daran die Lizenz für das KSC in den Eigenschaften des Admin-Servers zu erneuern. Grüße Alex​​​​​​​

Das ist kein Problem. Lizenzen lassen sich beliebig exportieren, aktivieren, etc. Du kannst eine Lizenz sogar auf mehreren Admin-Servern gleichzeitig einsetzen. Es liegt dann in der Verantwortung des Kunden, das Lizenzkontingent in der Summe einzuhalten. Grüße Alex

… wäre auch mit klmover.exe gegangen. Grüße Alex

Ohne Lizenz laufen nicht alle Schutzmodule. Wichtig für eine gute Erkennungsrate sind Verhaltensanalyse und KSN. Weiterhin läuft ohne Lizenz die Update-Aufgabe nicht - das Schutzprodukt bekommt keine Pattern-Updates. Ich würde dir empfehlen das sauber aufzusetzen und dann zu testen. Ein Standard-Test ist mit EICAR möglich: https://www.eicar.org/?page_id=3950 Grüße Alex

Wenn es ein verbreitetes Problem ist, würde ich dir empfehlen dich an den Support zu wenden: https://companyaccount.kaspersky.com/account/login Ticketnummer und Lösung gerne hier posten. Aber: Für mich ist das kein Workaround, sondern Best-Practice. Das Arbeiten mit Pool-Aufgaben bringt einige Vorteile und sorgt für eine aufgeräumte Verwaltung. Grüße Alex

Zu deinem Nachtrag: Der Netzwerkagent kann den Admin-Server nicht erreichen - ich tippe auf ein Konfigurationsproblem, siehe Oben. Auf dem Client lässt sich die Agent-Kommunikation mit klnagchk.exe prüfen, siehe Link Was mich wundert: Im Screenshot wird der Rechner mit dem FQDN “AAATESTKCL.lan” angezeigt. Kann eigentlich nicht stimmen. Ein FQDN sollte aus 3 Teilen bestehen: hostname.domäne.topleveldomäne Grüße Alex

Hallo Robert, wenn du die Testmaschinen nachträglich ins AD gehängt hast stimmen vermutlich die Berechtigungen und die Verbindungseinstellungen nicht mehr. Vor allem letzteres scheint mir ein Problem zu sein, da die Agent-Installation wohl durchläuft, sich der Agent aber nicht meldet - daher hängt die Installation bei 50%, die KES kann nicht installiert werden. Vergleiche bitte mal den Verbindungs-Eintrag im Installationspaket mit deiner Testumgebung und prüfe die Namensauflösung. Wenn ihr Kontakt zu einem Kaspersky-Partner habt besteht sicher auch die Möglichkeit den für eine begleitete Teststellung ins Boot zu holen. Das hilft Frust zu vermeiden. Grüße Alex

Leider kann ich dir nicht sagen, warum es mit deiner ursprünglichen Methode nicht funktioniert - sollte eigentlich. Allerdings empfehle ich generell die oben genannte Vorgehensweise. Damit greife ich über das Kontextmenü auf einen von mir definierten Satz an Aufgaben zu (wie eine Art Werkzeugkasten) - es wird nicht jedes Mal eine neue Aufgabe angelegt. Grüße Alex

Hallo flowe, bitte versuche mal eine Installationsaufgabe im Aufgaben-Pool zu erstellen und diese dann über das Kontextmenü auf einzelne oder mehrere Systeme zu starten: Grüße Alex

Hallo Robert, das in deiner Testumgebung das Discovery nicht funktioniert liegt vermutlich am fehlenden AD. Auch das Pushen von Installationen über das KSC funktioniert besser, wenn die Systeme Mitglied einer oder mehrerer Domänen sind - in Domänen-Netzen ist die Windows-Firewall bzgl. der erforderlichen Ports und Dienste offen. Folgende Vorgehensweise bzgl. Rollout würde ich empfehlen: Installation des Netzwerkagenten auf den Systemen, die geschützt werden sollen. Falls das per Push-Installation nicht möglich ist (s. O.) gibt es die Möglichkeit das lokal mit einem “Autonomen Installationspaket” durchführen. Beim Anlegen dieses Paketes wird das gesamte Setup inkl. Konfiguration in eine “installer.exe” gepackt.Wenn sich die Netzwerkagenten beim Security Center melden, sind diese unter “Nicht zugeordnete Systeme” sichtbar und lassen sich, falls gewünscht, mit Verschieberegeln automatisiert Verwaltungsgruppen zuordnen. Geht natürlich auch manuell über das Kontextmenü oder Drag+Drop. Die Installation des jeweiligen Schutzproduktes erfolgt dann über eine Installationsaufgabe. Ich arbeite hier gerne mit zwei Methoden: Installationsaufgabe als Poolaufgabe - die starte ich dann über das Kontextmenü “Alle Aufgaben” - Aufgabe starten” auf einzelne oder mehrere Systeme. Installationsaufgabe auf eine Geräteselektion - damit lassen sich Schutzprodukte automatisiert verteilen. In beiden Fällen lege ich Installationsaufgaben nicht als Gruppenaufgabe an, sondern hier: Auf Windows Servern ist der Einsatz von KS4WS empfehlenswert, hier sollte nicht die KES installiert werden. Daher trenne ich da bei der Geräteauswahl nach Betriebssystemen. Grüße Alex​​​​​​​

KES4B ist eigentlich die On-Prem-Lösung - ab 300 Lizenzen hast du aber die Möglichkeit die Cloud-Konsole einzusetzen https://support.kaspersky.com/KSC/CloudConsole/de-DE/5022.htm Wie bereits geschrieben: Auch mit einem On-Prem-Admin-Server lassen sich mobile Arbeitsplätze über Verbindungsprofile (Richtlinie des Netzwerkagenten) permanent ins Management einbinden - dazu wird keine Cloud-Konsole benötigt. Bzgl. deiner Anforderung an die Differenzierung bei den Ausnahmen: Würde ich über Richtlinienprofile steuern und diese z. B. an Tags binden https://support.kaspersky.com/KSC/12/de-DE/89258.htm In meiner Demoumgebung habe ich so z. B. die Festplattenverschlüsselung umgesetzt. Über das Tagging steuere ich, ob aus einem System die Festplatte verschlüsselt bzw. entschlüsselt werden oder unverändert bleiben soll. Im Richtlinienprofil müssen dann nur die abweichenden Werte editiert und die Einstellung mit dem Schloss verbindlich gesetzt werden: Bzgl. der Ausnahmen kann ich dir allerdings nicht sagen, ob der Schalter “Bei Vererbung Werte zusammenführen” greift - also ob die Ausnahmen der Richtlinie beibehalten und durch die Werte des Richtlinienprofils ergänzt werden. Das müsstest du mal testen. Alternativ zu den Richtlinienprofilen kannst du natürlich auch auf Gruppenbasis mit untergeordneten Richtlinien arbeiten. In diesem Fall funktioniert das Zusammenführen von Ausnahmen auf jeden Fall. Über die Platzierung der Geräte in der jeweiligen Unter-Gruppe mit untergeordneter Richtlinie steuerst du relativ einfach, welche Ausnahmen auf dem Gerät greifen. Grüße Alex

Hallo Freizeit_Admin, die Möglichkeiten, die du hast sind abhängig von den eingesetzten Lösungen und Versionen. Kannst du bitte dazu ein paar Informationen liefern? Generell gilt: Es kann nur einen (Agent) geben. Aber es lassen sich durchaus dynamische Konfigurationen (regelbasiert) zuweisen. Entweder über die Gruppenzuordnung mit dazugehörigen Richtlinien. Oder über Richtlinienprofilen, die nach bestimmten Regeln abweichende Einstellungen aktiv setzen können. Eine weitere und einfache Möglichkeit ist die mobile Richtlinie, die aktiv gesetzt wird, wenn der Client den Admin-Server nicht erreichen kann. Aber oft gibt es gar keinen Differenzierungsbedarf: Eine Ausnahme muss nicht unbedingt gerätespezifisch sein - wenn das Objekt auf einem anderen Gerät nicht vorhanden ist wird die Ausnahme einfach ignoriert. Ausnahmen würde ich auch nur setzen, wenn es ohne zu Störungen kommt (Anwendung funktioniert nicht, ist langsam, ...). Und dann so spezifisch wie möglich, um keine großen Löcher in den Schutz zu schneiden. Das mit der Update-Quelle regelt die Update-Aufgabe eigentlich auch mit Standardeinstellungen: Mobile Arbeitsplätze, die selten im Firmennetz sind und sich auch nicht per VPN-Verbinden lassen sich z.B. über ein Verbindungsgateway anbinden. Damit sind Systeme immer im Management, sofern eine Internetverbindung vorhanden ist (und Port TCP 13.000 raus geht). Weitere Infos zu mobilen Richtlinien und Verbindungsgateways findest du über die Suche hier im Forum und in den Handbüchern. Gerne bei Bedarf auch nochmal hier nachfragen. Grüße Alex​​​​​​​

Meines Wissens gibt es keinen Unterschied zwischen 9.4 und 9.6 - wie gesagt: Die Möglichkeiten im KSC sind bzgl. KS4Exchange nicht der Brüller. Falls du doch auf v9.6 gehen möchtest: Hier findest du am Ende einen Plugin-Uninstaller Link Grüße Alex

.. dann hast du es vermutlich schon installiert - was wird denn in den Eigenschaften des Admin-Servers unter “Erweitert” - “Informationen über installierte Programmverwaltungs-Plug-Ins” angezeigt? Bzw.: Erstelle doch einfach die Richtlinie - du müsstest KS4Exchange im Assistenten auswählen können. Grüße Alex

… einfach auf dem Admin-Server mit Doppelklick ausführen. Anschließend steht dir in der Management-Konsole des KSC im Assistenten für das Erstellen einer neuen Richtlinie auch KS4Exchange zur Verfügung. Grüße Alex

Hallo Carsten, vorweg: KS4Exchange lässt sich nur bedingt in des KSC integrieren. Das Plugin gibt dir nur die Möglichkeit das Monitoring über das KSC zu machen - und auch das nur eingeschränkt. Sofern das Plugin installiert ist kannst du eine Richtlinie für KS4Exchange erstellen und dort die Ereignisbenachrichtigung bzw. - speicherung einstellen. Entsprechend hast du die Events im KSC in den Berichten, den Protokollen und in der Gruppen-Ansicht unter “Verwaltete Geräte”. Die Downloads hole ich mir immer über die Support-Seite ... https://support.kaspersky.com/de/kse9#downloads … wobei hier inzwischen (leider) auf die Web-Seite weitergeleitet wird und hier musst du etwas nach Unten scrollen. Grüße Alex

Das gilt nur für das Agent-Paket, bei der KES ist diese Vorgehensweise nicht erforderlich bzw. zielführend. Der andere Punkt hört sich für mich nach einer fehlerhaften Konfiguration der Verbindungseinstellungen im Installationspaket des Netzwerkagenten an. Wurde KSC12.2 auf einem neuen Server installiert? Wie war die genaue Vorgehensweise? Schau bitte mal im Installationspaket des Netzwerkagenten, ob die Verbindungseinstellungen zu deinem Admin-Server passen: Auf einem verwalteten System lässt sich die Verbindung mit dem Tool “klnagchk.exe” prüfen, zu finden im Installationsordner des Netzwerkagenten. Das Tool muss in einer Kommandozeile mit Admin-Rechten ausgeführt werden und listet sehr detailliert die Parameter des Netzwerkagenten. Hier lässt sich in der Regel auch relativ schnell erkennen, woran es hängt. Häufige Ursachen für Verbindungsprobleme: Die Server-Adresse ist falsch oder kann nicht aufgelöst werden. Das Zertifikat stimmt nicht. Die Verbindungsports TCP 13.000 bzw. 14.000 gehen nicht durch.Grüße Alex PS: Bitte keine neuen Fragen an ein als gelöst markiertes Topic anfügen. Besser eine neue Frage einstellen.

Ist sinnvoll - mir fällt dazu nichts mehr ein. Du solltest für die beiden Fragen jeweils ein separates Ticket erstellen. Grüße Alex

Gerne Ticketnummer und Lösung posten - hilft vielleicht Anderen. Grüße Alex