Jump to content

MartinGe

Members
  • Content Count

    26
  • Joined

  • Last visited

About MartinGe

  • Rank
    Candidate
  1. Moin zusammen, mein letzter Stand ist, dass der Fehler mit dem SP1 für KES10 bei mir nicht mehr auftrat. Ich warte jetzt auf die Final. Mit dem Support bin ich auch so verblieben. http://forum.kaspersky.com/index.php?showtopic=311614 Probiert doch mal.
  2. Ich habe ein Ticket INC000003550879 aufgemacht. Melde mich wenn ich Ergebnisse habe. Danke schon mal bis hier her.
  3. Als Connection-Gateway ist er eingerichtet. Genau wie in KB10601 beschrieben. Ein Verbindung per Telnet sowie per http/https zu 13000 und 14000 ist möglich. Gruß Martin
  4. Hallo Alex, Da hatte Helmut ja schon vorgeschlagen die Adresse des Servers per klmover auf IP umzustellen. Hat leider keine Besserung gebracht. Ich dachte, dafür wäre die Update-Agenten/Verbindungs-Gateways da. So hatte ich das vorher eingerichtet. Mein Ziel ist es, die Server im LAN nicht direkt aus dem Internet erreichbar zu machen. Gruß Martin
  5. Das gilt für beide. Die Idee ist, dass ein Notebook, das mal im LAN und mal im Internet betrieben wird immer den Server erreichen kann. Und http://ksc.XXXXXX.de:13000 kann sowieso nicht sein, weil die 13000 ja der SSL Port ist.
  6. Hab ich. Bis auf den Hinweis dass das SSL Zertifikat nicht mehr stimmt ist der Fehler der gleiche.
  7. Hallo Forum, ich habe da ein kleines Problemchen mit einem Verbindungs-Gateway, bei dem Ihr mir bestimmt helfen könnt. Ich habe einen Update-Agenten in unserer DMZ Zone eingerichtet und ihn zum Verbindungs-Gateway gemacht. Über diesen möchte ich Clients im Internet an unseren KSC verbinden. Leider lässt sich die Verbindung nicht 100% sauber herstellen. Hier die Fakten: NetAgent 10.1.249c Security Center 10.1.249c Endpoint Security 10.2.1.23a Mein Security Center hat im LAN wie im Internet den selben Namen. ksc.XXXXXX.de Vom Internet zum Gateway, sowie vom Gateway zum Security Center sind nur die Ports 13000 und 14000 freigeschaltet. Es sind keine Verbindungsprofile eingerichtet. Der Update-Agent ist in seiner eigenen Gruppe. Die SSL Portnummer der Verbindung-Gateways ist auch 13000 Im lokalen LAN kann der Agent auf meinem Testclient sauber mit dem Security Center verbinden. klnagchk Von der DMZ aus kann das Verbindungsgateway sauber mit dem Security Center verbinden. klnagchk Versuche ich vom Internet aus zum Verbindungsgateway zu verbinden, erhalte ich eine Fehlermeldung. klnagchk Es ist ein Fehler auf der Transportebene beim Verbinden mit http://ksc.XXXXXX.de:13000 aufgetreten: Allgemeiner Fehler 0x4EC. Hier kommt der Teil den ich nicht verstehe. Portnummer ist die 14000. SSL-Portnummer ist die 13000. Die beiden Adressen lassen sich im Browser ansurfen. Vom LAN sowie vom Internet. http://ksc.XXXXXX.de:14000 https://ksc.XXXXXX.de:13000 Warum aber versucht der klnagchk plötzlich die 13000 unverschlüsselt zu erreichen? Und das auch nur wenn mein Agent im Internet hängt. Für Hinweise wäre ich sehr dankbar. Gruß Martin
  8. Hallo AbstractFactory, Kasperksy hat zwei Monate analysiert und mir vor einer Woche folgende Antwort geschickt. Hier ein Auszug: Ich hab mich damit nicht zufrieden gegeben. Mein Ansprechpartner möchte jetzt noch mal nachfragen und meldet sich wieder. Gruß Martin
  9. PF428 getestet. Problem existiert noch.
  10. INC000001534086 gehört auf jeden Fall auch dazu. Leider sind im CompanyAccount meine Antworten per E-Mail nicht gespeichert. So ist es wenig aufschlussreich.
  11. Noch nicht. Ich habe einen Thread im englischen Forum gestartet. Mit dem Ergebnis, ich möge mich an den Helpdesk wenden. Ein Blick in die GroupPolicy Events (gekürzt) vor und nach einer KES 10.2 Minimalinstallation (nur Programmkern) gibt weiteren Aufschluss. Vor KES Installation 00:00 GPO Dienst gestartet 00:04 Gruppenrichtlinie hat 2153 Millisekunden auf Netzwerksubsystem gewartet 00:04 Verarbeitung der Computerrichtlinie wird gestartet 00:04 Systemaufruf von Kontoinformationen erfolgreich 00:06 Computerstartrichtlinie in 1 Sekunde abgeschlossen Nach KES Installation 00:00 GPO Dienst gestartet 00:00 NLA (Network Location Awareness) konnte nicht gestartet werden 00:00 Gruppenrichtlinie hat 109 Millisekunden auf Netzwerksubsystem gewartet 00:00 Verarbeitung der Computerrichtlinie wird gestartet 00:01 Systemaufruf von Kontoinformationen fehlgeschlagen (4x) 01:05 Es wurde eine Netzwerkstatusänderung erkannt (?) 01:05 Systemaufruf von Kontoinformationen erfolgreich 01:05 Richtlinienverarbeitung aufgrund einer Netzwerkstatusänderung gestartet 01:07 Richtlinienverarbeitung aufgrund einer Netzwerkstatusänderung in 1 Sekunden abgeschlossen Es dauert eine Minute länger die Computerpolicies zu laden. Bemerkenswert ist, meldet man einen Domänenbenutzer vor Ablauf dieser Minute an, so geschieht dies ohne Fehler. Die Userpolicies werden Fehlerfrei geladen und verarbeitet. Die Netzwerkstatusänderung und das verarbeiten der Computerpolicies nach eine Minute bleibt davon unbeeinflusst. Zu erwähnen wäre noch, die GPO Verarbeitung läuft nach der Deinstallation von KES auch nicht mehr richtig. Ich hab das Freitag so noch mal an den Helpdesk gemeldet. Mal sehen was raus kommt.
  12. I am afraid, uninstalling the NDIS Filter did not change anything.
  13. On a fresh Windows I installed a KES Core without any protection features. On the next reboot the GroupPolicy EventLog starts with a Event 6323 (Network Location Awareness could not start) and pending error like 7017 (Cant get account information). Everything worked fine before KES Installation. PS: We are using german Windows 7, so I am translating all error messages.
×
×
  • Create New...

Important Information

We use cookies to make your experience of our websites better. By using and further navigating this website you accept this. Detailed information about the use of cookies on this website is available by clicking on more information.