FrankB

scheinbar hat sich noch niemand heran getraut? es gibt bis heute noch keine Erfahrungsberichte im Forum, weder gute noch schlechte Grüße Frank

habe bereits am Montag 140 Geräte inkl. Server (KSWS soll ja abgelöst werden) problemlos an einem Nachmittag umgestellt, ABER: An einem anderen Standort haben sich auf einmal die Lizenzen verfangen (wir sind schon knapp an der Grenze), Kaspersky verzählt sich da gerne. Da liefen dann einige zunächst nicht wg. Lizenzverstoss. Das hat sich dann aber innerhalb von ca. 1h von alleine gelöst. Also nicht nervös werden;-) Ein Phänomen, das wir uns nicht erklären können, war das aus einem VLAN alle Rechner rausgeflogen sind, keine Verbindung mehr zum Agent und weder Domain-Anmeldung noch RDP möglich. TCP/IP und Ping gingen weiterhin. So als würde der Kaspersky die Windows-FW übernehmen und alles blockieren. Es war sehr mühsam an die 400km entfernten Maschinen-PCs heranzukommen und eine hat es bei den Reparaturarbeiten gehimmelt. Irgendwas hat die Kommunikation im Netzwerk dazu gebracht, daß die Switches nicht mehr wollten. Nachdem wir SpanningTree und LoopProtection aktivierten, kamen auf einmal die PCs wieder rein. Aber es gab keine Alarme bzgl. Schleifen oder falscher Verkabelung, auch keine gleichzeitig stattfindenden Umbauten. Was das eine mit dem anderen zu tun haben soll, können wir uns wirklich nicht erklären, aber es hat geholfen. Auf einem Server waren nach dem Update sowohl die alten als auch die neuen Kaspersky-Dienste (neu mit Nummer) gleichzeitig, aber nur die neuen aktiv. Hier mußte das KES11.10 nochmals deinstalliert und nach einem Reboot mit dem Remover aufgeräumt werden. Dann wieder drauf und alles OK. Der PRTG-Ping auf die Kaspersky-Services ist deutlich länger geworden, die Clients aber gefühlt etwas schneller und zuverlässiger über den KSC zu steuern. Künftig geht ein Produktupgrade auch ohne Rechnerneustart, wenn man die Option findet und aktiviert, steht aber auch im Readme;-)) Grüße Frank

habe dir eine PM hierzu geschickt

das Problem muß sich mal wieder durch die WindowsUpdates eingeschlichen haben, man merkt es halt nicht gleich

Hallo Alex, das wäre mal wieder zu einfach gewesen. UDP-Regel per GPO nachgepflegt und ausgerollt, gpupdate etc. durchgeführt. Beide Rechner stehen nebeneinander im selben LAN, selbst das Abschalten der FW macht keinen Unterschied. Der eine geht, der andere nicht. Beide melden sich aber regelmäßig und zeigen ihren Status. Geholfen hat schlußendlich den Agent runterzuschmeissen und neu über den KSC draufzubügeln. Hat dann sofort wieder wie gewünscht funktioniert. Werde es nun etwas komfortabler per KSC über den schon installierten Agent einfach nochmals drüberbügeln lassen. Das vergebene Deinstallations-Passwort braucht man scheinbar nicht, wenn es allein per Agent installiert wird. Grüße Frank

Hallo, ich suche gerade wie ein blöder und finde einfach den Unterschied nicht. Alle PCs (z.B. Laptops) haben eine gemeinsame Richtlinie. Habe: KSC 13.1 und KES 11.9 im Einsatz. Ein Gerät kann ich im KSC (Rechtklick/Eigenschaften) auswählen und dessen Aufgaben starten oder stoppen, ebenso den Virenschutz an sich. Auf dem anderen ist das alles nur ausgegraut. Beide Rechner sind verfügbar und haben die Richtlinie synchronisiert. Wo kommt das her und wie bekommt man es hin, daß diese Sperre unterbleibt? Grüße Frank

Hallo, wir nutzen das eingebaute Patchmgmt für die Pflege von Drittsoftware wie KeePass oder Teamviewer. Das funktioniert eigentlich recht gut, außer in diesem Fall: Zunächst wird ermittelt, wer welche Patches benötigt und das sieht dann so aus, je nachdem, wieweit Kaspersky schon Updates bereitgestellt hat. Dann gibt es natürlich eine entsprechende Aufgabe, um das Einspielen anzustossen: D.h. er hat eigentlich etwas zu tun und weiß auch bei wem und was. Führe ich allerdings diesen Job aus, passiert folgendes: Irgendwie passt das nicht zusammen. Weiß jemand woran das liegen kann? Ansonsten mache ich halt in Ticket auf. Grüße Frank

In der Tat besteht die Lösung darin, erst alles zu sichern, eine Deinstallation durchzuführen und dann von vorne zu beginnen. Nur dann kommt der Dialog für die Datenbank. Es geht aber smooth, da das KLBAckup anschließend eingelesen wird und man somit zunächst mit einer leeren gerade neu angelegten Datenbank starten kann (macht das Setup). Ein Umzug der DB von Server zu Server entfällt damit bzw. nimmt einem die KLBackup-Prozedur ab. Hier das Original vom Support dazu: Das KSC muss auf die neue DB installiert werden, damit diese genutzt werden kann. Folgendes Vorgehen ist empfohlen: 1) Zur Sicherheit ein Backup des gesamten Servers erstellen -> SC-Share und KL-Share zusätzlich separat sichern -> die alte DB wird vom SQL-Server gelöscht, daher vorher auf SQL-Ebene einen Export/Sicherung fahren (wird aber eigentlich nicht benötigt, da die DB auf dem neuen Server per Setup angelegt wird) 2) klbackup erstellen (KSC Backup mit Struktur, Richtlinien und Aufgaben) https://support.kaspersky.com/KSC/13.2/de-DE/13288.htm -> Sicherung anlegen und ggf. diese noch woanders ablegen, weil beim Deinstallieren der SC-Share ggf. gelöscht wird 3) KSC deinstallieren 4) KSC neu installieren und hierbei die neue DB auswählen -> es darf beim Installieren noch keine neue DB vorhanden sein -> der WETROPA\sa_Kaspersky-User benötigt dbo- und SysAdmin-Rechte auf dem SQL-Server 5) KSC ausführen und den Schnellstartassistenten soweit durch klicken bis Sie theoretisch ein leeres und funktionsfähiges KSC bedienen könnten -> PlugIns kann man überspringen, die werden später restauriert 6) klbackup.exe ausführen und das vorhin erstellte Backup aus Schritt 2) einspielen -> nach dem Restore ist ein Serverneustart erforderlich, weil sonst die Konsolen-Anmeldung nicht funktioniert Ich hoffe, das hilft Ihnen weiter. Bei Rückfragen gerne nochmal melden.

Konnte es lösen indem ich das Netz mal für einige Zeit mit Internet versehen und das WindowsUpdate im Netz suchen gelassen habe. Aus einmal lief der Job wie von Zauberhand durch und KESS wurde vom KSC aus installiert. Der Nachtrag bezieht sich leider nur auf die MS-Zertifikate und die PowerShell-Befehle funktionieren bei W7 Embedded nicht. “parameter not recognized” Man muß irgendwie offline Wurzelzertifikate für die von Kaspersky genutzten Zertifikate aktualisieren. Verteilen könnten wir die mittels GPO, aber leider nur bei Domain-Mitgliedern. Alte XP-Kisten bleiben ausgesperrt. Ich habe noch ein TIcket offen und melde mich, sobald eine Antwort kommt. Grüße Frank

Hallo, versuche gerade unsere Maschinen (embedded) von KESS3.0 auf 3.1 zu migrieren. Alle haben die gleiche Systemzeit vom AD erhalten. Diejenigen mit Internetzugang laufen problemlos durch, die anderen melden mir diesen Fehler: “Die Remote-Installation auf dem Gerät wurde mit Fehler abgeschlossen: Beim Versuch, die Programminstallation zu starten, ist ein Systemfehler aufgetreten. (Die Signatur des Zeitstempels bzw. des Zertifikats konnte nicht bestätigt werden oder ist ungültig.)” Es handelt sich hierbei um W7-embedded-Geräte, somit ohne regelmäßige WindowsUpdates, werden aber sonst per WSUS versorgt. Brauchen die zum Überprüfen der Signatur Internetzugang? Gibt es keine Möglichkeit einer echten Offline-Installation mehr? Grüße Frank

Hallo, suche mir gerade einen Wolf und möchte eigentlich nur prüfen, was bei uns bzgl. KES, KESS und KSWS noch zu patchen ist. Wie kommt man an diese Info zu dem jeweils aktuellen (critical) PatchFix und muß ich die immer beim Support anfordern? Grüsse Frank

Hallo, ist diese Lösung bei 13.1 immer noch so? Finde es reichlich umständlich. Die funktionierende Installation nicht einfach umleiten zu können, sonderen den KSC-Adminserver zu deinstallieren und dann mit geändertem SQL-Server-Ziel neu zu installieren ist schon recht merkwürdig. (Die Datenbank manuell umzuziehen ist übrigens weitaus schneller erledigt, als die Anleitung für “Wechsel auf neuen KSC-Adminserver samt DB” es vorschlägt.) Habe mir jedenfalls einen Wolf gesucht, der KSC kann die aktuellen SQL-Server-Parameter readonly anzeigen und ein Backup von der DB machen, mehr aber scheinbar nicht. Die Installation kann man über die Systemsteuerung “ändern”, das bedeutet aber auch nur deinstallieren, Komponenten hinzufügen/weglassen, aber mehr auch nicht. Habe gestern beim Support schon ein Ticket hierzu geöffnet, läßt aber auf sich warten.

bei uns läuft der Schutz unverändert, aber: es geht kein Reparieren/Deinstallieren mehr vom KES und von daher auch kein Upgrade auf eine neue Version nimmt man den MS-KB vom System, gehts wieder, aber das ist leider bei >>100 Einheiten keine Option hier die Info von M$ dazu: https://docs.microsoft.com/en-us/windows/release-health/status-windows-10-21H1#2759msgdesc

Hallo, habe gerade auf einem Testrechner KES11.7 ausgerollt. Hier erscheint die Anwendung in einem Design wie vor 40 Jahren, als die Röhren noch nachleuchteten und der Rest dann tiefschwarz war. Neuerdings heißt das Feature wohl “Dark Mode”. Kann man diesen wenigents nach Tageszeit, nach Computerlaune (aktuelles Design) oder sonstwie manipulieren oder so hinbekommen, daß es wieder Schwarz auf Weiß leserlich erscheint? Aktuell würden die Anwender hier einschlafen und besonders kontrastreich bzw. leserlich ist dies nicht. Bin für jeden Tip dankbar. Frank

Man kann die Verfügbarkeit von Software-Updates (Drittsoftware) indirekt prüfen, indem man im KSC auf Programmverwaltung\Software-Updates geht. Wurden die verwalteten Clients inventarisiert (geht eigentlich quasi automatisch, wenn per Kaspi die Software ausgerollt wird, ansonsten einen Job dafür laufen lassen), dann werden für die bekannten installierten Programm alle verfügbaren Updates angezeigt. Diese Liste schwankt auch sehr, denn sind auf den Clients diese Updates einmal eingespielt, verschwinden die wieder in der Liste, da nicht mehr benötigt. (Da hatte ich anfangs meine Verständnisprobleme mit.) Etwas merkwürdig kann es bei Versionsupdates zugehen, wenn Firefox ESR mit v78 und v91 gleichzeitig angezeigt werden, wobei ein Update über Versionsgrenzen hinweg eigentlich möglich ist. Da hilft es nichts und man muß einmal eine v91 ausrollen, sonst bleiben Clients bei der letzten v78 kleben. Die von DidiSurfer beschriebene Vorgehensweise braucht man nur, wenn man noch nicht ausgerollte Software prüfen/verteilen möchte. Für eine besondere Qualitätskontrolle und Metadatei-Pflege von Updates, die bereits als MSI-Dateien verfügbar sind und dessen Installationsschalter bekannt sind, benötige ich keine Wochen. Dieses Argument bezieht sich eher auf die Kaspersky-eigenen Updates, die es oft schon zum Download gibt (und über die AlexCad hier i.d.R. informiert), aber noch nicht automatisch im KSC. Das dauert gewöhnlich wirklich einige Wochen. Ich habe tastsächlich mal einen mehrtägigen Kaspersky-Enterprise-Kurs belegt und da war genau dieses Thema der Softwareverwaltung- und Pflege KEIN Thema, der Kursleiter hatte schlichtweg keine Ahnung davon und ihm konnte es in seiner Firma scheinbar auch keiner erklären, noch gab es Erfahrungen hierzu. Und dies bei einem Hauptargument für die Kaufentscheidung, weil man quasi ein zweites Management-Tool miterwirbt. Es dann so zu vernachlässigen und in den Hintergrund zu stellen, finde ich schade. Zeitweise denke ich deshalb immer wieder daran, doch auf SCCM oder ähnlichem umzusteigen. Grüße Frank