Lizenzaktivierung: Fehler auf Transportebene

[Luckysh0t]

Hallo zusammen,

 

wir nutzen in unserre Umgebung “Kaspersky Endpoint Security for WIndows”.

Auf einem unserer Clients (Windows 10 Pro) lässt sich der Agent mit oben genannten Fehler nicht aktivieren - weder als Aufgabe über den Administrationsserver (Version 13) noch manuell als Key direkt am Client.

 

Auf anderen Clients im selben Netzwerk/Firewall funktioniert dies ohne Probleme.

 

Installiert ist

• Adminagent in Version 13.x..x.x
• Av Agent in Version 11.6 Strong Encryption

MS Defender ist nicht vorhanden, Windows ist aktuell.Auch Testweiße die WIndows Firewall zu dekativieren half nicht. des weiteren ist kein Proxy eingetragen.

 

Woran könnte dies also noch liegen ?

 

Gruß

Lucky

[alexcad]

Hallo Lucky,

willkommen im Forum.

Vorweg: Wenn KES installiert ist sollte die Windows-Firewall eigentlich nicht laufen. In der Systemsteuerung von Windows 10 sieht das dann so aus.

 

Frage zu deinem Problem: Wird die Richtlinie auf dem System übernommen und was ist hier bzgl. “Proxyserver für die Aktivierung” konfiguriert? Du findest diese Einstellung hier.
 

Es ist sicherlich auch sinnvoll die Kommunikation des Netzwerkagenten zu prüfen. Dazu führst du bitte auf dem System das Tool “klcsngtgui.exe” mit Admin-Rechten aus.
 

 
Das Tool gibt schon mal zwei wichtige Infos:

• Stimmt die Serveradresse?
• Wann war die letzte Verbindung zum Server? Das sollte nicht mehr als 15 Minuten her sein.

Bei Bedarf lässt sich mit “klnagchk” eine erweiterte Diagnose aufrufen.

Hierbei werden dann alle Kommunikationsparameter gelistet und geprüft.

Grüße
Alex​​​​​​​

[Luckysh0t]

Hallo Alex,

 

Vorweg: Wenn KES installiert ist sollte die Windows-Firewall eigentlich nicht laufen. In der Systemsteuerung von Windows 10 sieht das dann so aus.

Wir benutzen nur den AV Part von Kaspersky - die Windows Firewall verwalten wir selbst.

 

Wird die Richtlinie auf dem System übernommen und was ist hier bzgl. “Proxyserver für die Aktivierung” konfiguriert?

Ist richtig konfiguriert (Haken ist gesetzt) - bei den anderen Clients in der selben Gruppe/Richtlinie funktioniert es ohne Probleme.

 

• Stimmt die Serveradresse?
• Wann war die letzte Verbindung zum Server? Das sollte nicht mehr als 15 Minuten her sein.

  Adresse stimmt

  Verbindung war zum Testzeitpunkt gerade mal 4 Minuten her.

 

Statusmeldungen, Aufgaben etc. lassen sich alle ohne Probleme über den Adminserver starten - mit Ausnahme der Lizenzaktivierung..

 

Gruß

 

Daniel

[Grodomin]

Hallo @Luckysh0t

schau mal bitte ob am Client auch der Port 17000 TCP Client in Richtung KSC freigegeben ist.

Der Port fehlte uns immer, wenn etwas keine Lizenz bekam…

 

MfG

[alexcad]

 

Wir benutzen nur den AV Part von Kaspersky - die Windows Firewall verwalten wir selbst.

Hallo Daniel, 

da würde ich zur Kaspersky-Firewall raten, da diese auf Basis von Reputations-Informationen dynamische Regeln vorsieht. 
Die Windows-Firewall kennt nur statische Paket-Regeln.

Grüße
Alex

[alexcad]

… schau mal bitte ob am Client auch der Port 17000 TCP Client in Richtung KSC freigegeben ist.

Der Port fehlte uns immer, wenn etwas keine Lizenz bekam…

 

… ergänzend dazu: Hier findest du ein Netzwerkschema mit Erklärungen zu den benötigten Ports.

https://support.kaspersky.com/ksc/13.1/de-DE/183040.htm

 

Alternativ kannst du auch in der KES-Richtlinien den Haken bei ...
 

… rausnehmen, dann geht der Client für die Lizenz-Aktivierung direkt ins Internet.

Grüße
Alex

[Luckysh0t]

@Grodomin 

Danke für den Tip, aber bei anderen Clients im selben Subnetz/VLAN klappts ja auch.

Hat aber nicht geholfen.

 

@alexcad 

Das hat nun geklappt, ist nur jetzt die Frage, warum er den Adminserver nicht nutzen kann...alle anderen Clients/Server aus dem gleichen/anderen Netzwerk erreichen den ohne Probleme und aktivieren sich auch brav..

 

 

Grüße

Daniel

 

 

[Grodomin]

@Luckysh0t  hab mal foglendes gelernt

• 90 % aller Exchange Probleme sind AD-Probleme
• 90 % aller AD-Probleme sind DNS-Probleme

Wenn nur ein einzelnes Gerät im gleichen Subnetz betroffen war, würde ich auf die Namensauflösung tippen :-D

[alexcad]

… 

@alexcad

Das hat nun geklappt, ist nur jetzt die Frage, warum er den Adminserver nicht nutzen kann...alle anderen Clients/Server aus dem gleichen/anderen Netzwerk erreichen den ohne Probleme und aktivieren sich auch brav..

 

… ist aber eigentlich ein klares Indiz dass Grodomin richtig liegt. Ich hätte die Ursache des Problems damit auch bei der Kommunikation über Port 17.000 TCP vermutet.

Um zu prüfen, ob Kommunikation zu bestimmten Zielen über einzelne Ports durchgeht setze ich in der Regel Telnet ein. 
 

Wenn die Telnet-Verbindung ohne Fehler zustande kommt ist der Port offen und erreichbar.
 

 

Falls Telnet auf dem Client fehlt: Die einfachste Möglichkeit Telnet zu installieren ist der Aufruf über PowerShell.

DISM /online /enable-Feature /FeatureName:Telnetclient

 

Grüße
Alex