none
Verbindungsabbrüche zum Terminalserver - Fehler: "TermDD" ID56 RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo liebes TechNet,

    ich habe meine Anfrage an Microsoft Answers schon einmal gestellt und wurde darauf hingewiesen, dass es sinnvoller wäre mich damit hierher zu wenden. 

    Ich habe ein großes Problem bei einem unserer Server - es geht um einen virtualisierten Windows Server 2008 R2.

    Und zwar finden relativ regelmäßig Verbindungsabbrüche zu unserem Terminalserver statt - nach einigen automatischen Verbindungsversuchen der RDP-Sitzung geht es dann weiter. Der Fehler tritt etwa 1-2 Mal pro Woche auf. Manchmal auch 14 Tage gar nicht.

    Aufgefallen ist mir im Ereignislog daraufhin die ID56 mit Quelle "TermDD".

    "Von der Terminalserver-Sicherheitsschicht wurde ein Fehler im Protokollablauf erkannt, und die Clientverbindung wurde getrennt. Client-IP: ***"

    Dieser Eintrag deckt sich mit den Ausfallzeiten. 

    Dazu habe ich mir folgende Lektüre zu Gemüte geführt: 

    http://blogs.technet.com/b/askperf/archive/2010/03/25/the-curious-case-of-event-id-56-with-source-termdd.aspx

    In den Binären Daten bestehen die letzten 4 Byte aus unterschiedlichen Inhalten.

    Es treten folgende auf "710000C0",  "06000AD0" und "B50000D0" 

    Ich denke es müssten nach der Anleitung dann folgende Codes dabei rauskommen:

    "C0000071", "C00A0006" und "C00000B5"

    Laut "err.exe" bedeutet das dann:

    "STATUS_PASSWORD_EXPIRED", "STATUS_CTX_CLOSE_PENDING" und "STATUS_IO_TIMEOUT"

    Während der erste noch nachvollziehbar ist, obgleich ich nicht glaube, dass es im Falle eines tatsächlich abgelaufenen Passwortes nach 5 Verbindungsversuchen wieder klappt, verstehe ich die anderen überhaupt nicht mehr.

    Was genau habe ich getan?

    - Linkspeed der Netzwerkkarte sowohl fest eingestellt als auch auf Automatisch

    - Netzwerkkarte des Terminalservers über den vSphere-Client neu installiert und die Treiber geupdated

    - der günstige Netgear-Switch wurde gegen einen **** teuren HP-Switch ausgetauscht

    Ich wäre für weitere Ansätze dankbar!

    Vielen Dank im Voraus für den Support.


    • Bearbeitet Teodora MilushevaModerator Freitag, 5. Dezember 2014 06:54 Ich habe die Frage, die Sie an Microsoft Answers gestellt haben hier gepostet, um die bestmögliche Antwort zu bekommen.
    Donnerstag, 4. Dezember 2014 17:48
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden

    Hallo,

    mich würde noch mal interessieren auf was für Hardware der ESX Server läuft. Und was für eine Version der Vmware.

    Wenn es HP ist dann gibt es da einen BUG der Firmware des Management Interfaces "ILO-Interface". Das hat bei uns auch das Problem ausgelöst. Das RDP Session auf TS-Servern getrennt worden sind.

    Wir haben mit der Version 1.51. nun keine Probleme mehr. Ich glaube der BUG wurde mit der Version 1.41 behoben. Aktuell ist 2.03.

    Gruß
    Stefan

    st_fbg


    Dienstag, 9. Dezember 2014 20:28
    |
  • Question
    Anmelden
    1
    Anmelden

    Nochmals vielen Dank für die Hilfe.

    Schuld für den IO_Timeout und die Probleme mit dem Zeitserver sowie die daraus resultierenden disconnects war ,wie DevOn99 richtig vermutete, ein Backupjob. Der Job war nicht verdächtig, da er am Samstag gestartet wurde. Allerdings lief der Job knapp 40 Stunden und besagter Terminalserver war von der Verarbeitungsreihenfolge als letztes dran - daher der Ausfall.

    Nach wie vor nicht geklärt ist der andere unregelmäßig auftretende TermDD-Fehler: "STATUS_CTX_CLOSE_PENDING". Der ist lange nicht so wichtig, da er nur zu einzelnen Trennungen fühlt - sprich es wird nur ein einziger Client getrennt, nicht alle. Wäre natürlich trotzdem schön, wir bekämen das in den Griff.

    @Stefan: Der ESX ist ein ProLiant ML370 G6 mit einem HP-ESXi-5.0.1 Standard ISO. ILO ist ein Version 2 Advanced in der Firmware-Version 2.07 von August 2011. 

    Dienstag, 16. Dezember 2014 09:41
    |

Alle Antworten

  • Question
    Anmelden
    2
    Anmelden

    Hallo,

    hatte selbiges Problem nach Installation einer Software die mit Zertifikaten arbeitet...

    Hier war dann der Kryptografie-Dienst der Auslöser, der dann tw. ebenfalls Fehlermeldungen warf.

    Falls im EventLog IDs 7031 auftauchen, bitte diesen Eintrag lesen.

    http://blog.blackseals.net/2014/07/17/remotedesktopdienste-wurde-unerwartet-beendet/

    Bei uns hat die Neuinstallation der o.a. Software (DATEV-Sicherheitspaket) geholfen.

    Freitag, 5. Dezember 2014 08:17
    |
  • Question
    Anmelden
    0
    Anmelden

    @Teodora: Danke für das Kopieren des Inhaltes. Sehr nett!

    @Jimmy:

    Den Fehler "7031" kann ich nirgendwo entdecken, er taucht "leider" nicht auf. 

    Es gibt bei uns sonst auch kaum Programme auf dem TS - neben Office eigentlich nur eine kleine SQL-Datenbank. 

    Vielen Dank für Deine Antwort.


    Freitag, 5. Dezember 2014 09:16
    |
  • Question
    Anmelden
    1
    Anmelden

    Tritt das Problem bei Verbindungen von allen Clients auf, oder nur von einem?

    Wir hatten das Problem schon öfter. Jedesmal war irgendeine Software auf einem Client im Netz schuld.

    Drucker/Scanner-Treiber eines freigegebenen Druckers, Dymo-Label-Writer, Trend Micro AV. Besonders, wenn z.B. ein Drucker Discovery-Dienste installiert würde ich gucken.

    Einmal war es eine Software, die nicht mal auf dem betreffenden Client installiert war. Es reichte, wenn jemand im Netz scannen wollte. Wir haben die Zeitpunkte dann analysiert und sind so auf das Problem gestoßen. Fröhliche Suche!

    Bei mit HV virtualisierten Servern hatten wir schon Probleme wegen NIC-Teaming und Virtual Maschine Queue in Verbindung mit bestimmten NICs (Broadcom).

    Freitag, 5. Dezember 2014 12:40
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo DevOn,

    wenn das Problem auftritt, wird im Ereignislog zwar eine bestimmte Client-IP genannt, es werden nach meiner Erfahrung aber alle diejenigen getrennt, die zu diesem Zeitpunkt eine aktive Verbindung zum TS haben. Ob das immer so ist kann ich nicht sicher sagen.

    Auffällig in unserem Falle ist es, dass der Fehler fast jeden Montag in der Zeit von 12 bis 13 Uhr auftritt, aber nicht ausschließlich - es gibt auch Fehler an anderen Tagen / Uhrzeiten. Jedoch viel seltener.

    Der Server läuft auf einem HP ESXi-Host.

    Sollte ich mich mit diesem Problem vielleicht an Microsoft direkt wenden? Haltet Ihr das für sinnvoll und wer wäre der richtige Ansprechpartner?

    Dienstag, 9. Dezember 2014 07:28
    |
  • Question
    Anmelden
    0
    Anmelden

    Update:

    Ich habe mittlerweile herausgefunden, dass der TermDD-Fehler "B50000D0" ("STATUS_IO_TIMEOUT" ) immer dann auftaucht, wenn unmittelbar vorher die Systemzeit auf dem TS korrigiert wurde - und zwar um jeweils mehr als 2 Minuten. Direkt darauf (innerhalb von 15 Sekunden) folgt der TermDD B500000D0.

    Ich kenne zwar die Ursache für das Zeitproblem noch nicht, da alle anderen Server korrekt laufen und keine Abweichungen über 10 Sekunden vorweisen können, allerdings schätze ich stark, dass mit der Behebung dieses Zeitproblems auch dieser Fehler verschwinden wird - es bleibt zu klären woher "STATUS_PASSWORD_EXPIRED" und "STATUS_CTX_CLOSE_PENDING" kommen.




    Dienstag, 9. Dezember 2014 10:43
    |
  • Question
    Anmelden
    1
    Anmelden
    Wenn ihr kostenlose Supportfälle habt, kannst du es versuchen. Schaden kann es nicht, aber Zeit verschlingen.

    Ich würde versuchen herauszufinden, was am Montag zwischen 12 und 13 Uhr los ist.

    Häufig ist z.B. auch ein zeitgesteuerter Anti-Virus-Scan (oder Signatur-Updates) ein Problem. Kannst du die Performance überwachen?

    Was ist zu der Zeit im Netz los? Backups? Andere Software, die "etwas" tut? User, die bestimme Software nutzen? E

    Ereignisprotokolle der Server und Clients zum Zeitpunkt überprüfen. Nicht nur auf Fehler, sondern alles.

    Aufgabenplanung überprüfen usw.

    Versuche mal Lösungen in: http://blogs.msdn.com/b/scstr/archive/2012/02/29/how-to-troubleshoot-the-terminal-server-security-layer-detected-an-error-in-the-protocol-stream-and-has-disconnected-the-client-client-ip-and-the-rdp-protocol-component-x-224-detected-an-error-in-the-protocol-stream-and-has-d.aspx

    Aus unserer Erfahrung sind viele der Features fürs Netzwerk wie RSS, VMQ usw. immer noch problematisch für Windows-Systeme. Meist in Verbindung mit bestimmter Hardware. Die Probleme treten dann meist sporadisch auf, wenn "etwas" anderes im Netz es auslöst. Das gilt leider auch noch für Server 2012 R2, wie wir bei Hyper-V Hosts mit Broadcom-NICs und NIC-Teaming feststellen mussten. Allerdings gibt es meistens auch immer einen auslösenden "externen" Faktor, wie z.B. hohe Netzlast auf einer VM, 3.Party-Soft usw.



     
    Dienstag, 9. Dezember 2014 19:22
    |
  • Question
    Anmelden
    1
    Anmelden

    Hallo,

    mich würde noch mal interessieren auf was für Hardware der ESX Server läuft. Und was für eine Version der Vmware.

    Wenn es HP ist dann gibt es da einen BUG der Firmware des Management Interfaces "ILO-Interface". Das hat bei uns auch das Problem ausgelöst. Das RDP Session auf TS-Servern getrennt worden sind.

    Wir haben mit der Version 1.51. nun keine Probleme mehr. Ich glaube der BUG wurde mit der Version 1.41 behoben. Aktuell ist 2.03.

    Gruß
    Stefan

    st_fbg


    Dienstag, 9. Dezember 2014 20:28
    |
  • Question
    Anmelden
    1
    Anmelden

    Nochmals vielen Dank für die Hilfe.

    Schuld für den IO_Timeout und die Probleme mit dem Zeitserver sowie die daraus resultierenden disconnects war ,wie DevOn99 richtig vermutete, ein Backupjob. Der Job war nicht verdächtig, da er am Samstag gestartet wurde. Allerdings lief der Job knapp 40 Stunden und besagter Terminalserver war von der Verarbeitungsreihenfolge als letztes dran - daher der Ausfall.

    Nach wie vor nicht geklärt ist der andere unregelmäßig auftretende TermDD-Fehler: "STATUS_CTX_CLOSE_PENDING". Der ist lange nicht so wichtig, da er nur zu einzelnen Trennungen fühlt - sprich es wird nur ein einziger Client getrennt, nicht alle. Wäre natürlich trotzdem schön, wir bekämen das in den Griff.

    @Stefan: Der ESX ist ein ProLiant ML370 G6 mit einem HP-ESXi-5.0.1 Standard ISO. ILO ist ein Version 2 Advanced in der Firmware-Version 2.07 von August 2011. 

    Dienstag, 16. Dezember 2014 09:41
    |
  • Question
    Anmelden
    1
    Anmelden
    Glückwunsch, dass du es gefunden hast. Dieses Suchen "was Passiert hier im Netz zu dieser Zeit" ist zeitaufwendig, führt aber oft zum Erfolg.
    Dienstag, 16. Dezember 2014 09:52
    |