none
RD Session Broker 2008 Server R2 RRS feed

  • Frage

  • Habe ein Problem mit dem Sessionbroker, unter Server 2008 R2 Standart - Firewall --> NAT ins interne Netz - TS Farm mit 3 TS Servern 2008 R2 Standard SP1 im NLB - 2 DC's Servern 2008 R2 Standart SP1 auf DC1 läuft der RD-Sessionbroker Intern funktioniert der Sessionbroker ohne Probleme und auch Fehlerfrei!!! Wenn ich aber nun Versuche von Extrene PC zu zugreifen, funktioniert der Zugriff nur sporadisch. Wenns nicht Funktioniert kriege ich Folgende Meldung: "Der Client konnte keine Verbindung mit Remotecomputer herstellen. Möglicherweise sind Remoteverbindungen nicht aktiviert oder der Computer ist überlastet und kann keine neue Verbindungen annehmen. Netzwerkprobleme können auch dazu führen, dass die Verbindungen nicht hergestellt werden kann. Stellen Sie die Verbindung zu einem späteren Zeitpunkt erneut her. Sollte das Problem weiterhin bestehen, wenden Sie sich an den Administrator" Hat einer Vielleicht ne Idee woran das liegen könnte? Oder hat eine das gleiche Problem gehabt und hat eine Lösung für mich? Aus dem Eventlog's werde ich auch leider nicht schlauer :(
    • Typ geändert fragger85 Donnerstag, 5. April 2012 15:03
    Mittwoch, 7. Dezember 2011 13:30

Alle Antworten

  • Prüfe mal die Namensauflösung, wenn die RDP-Verbindung nicht hergestellt werden kann.

    Zum Beispiel: nslookup <Remotehost>

    Sonntag, 11. Dezember 2011 22:30
  • Namensauflösung funktioniert ohne Probleme. Denke das problem liegt am Nat ich hab nur leider kein Ansatz warum :(
    Montag, 12. Dezember 2011 12:38
  • Wenn ich aber nun Versuche von Extrene PC zu zugreifen, funktioniert der Zugriff nur sporadisch.

    Das entscheidende Wort ist "sporadisch"!

    Die von dir beschriebene Fehlermeldung kommt fast immer dann, wenn die Namensauflösung nicht stimmt, seltener, wenn tatsächlich das Netzwerk nicht zur Verfügung steht.

    Kann es sein, dass beim externen PC mehrere DNS-Server eingetragen sind und einer davon den Namen des Sessionbrokers nicht auflösen kann?

    Oder ist der Sessionbroker multihomed und auch mit mehreren IP-Adressen im DNS eingetragen, aber nur eine Adresse davon im NAT-Router?

    Andere Frage: Benutzt du gar kein RD-Gateway? Dann würdest du nämlich von Extern eine HTTPS-Sitzung eröffnen, in der RDP getunnelt wird. Erst das Gateway würde sich zum Sessionbroker verbinden, das wäre aber schon Intern!

    Montag, 12. Dezember 2011 13:47
  • Nein nutze ich nicht aber werde mal über VPN probieren das sollte eigentlich gehen denke ich... und wenn alle stricke reißen werde ich wohl ein RD- Gateway aufsetzen.

     

    Zu der Auflösen des Sessionbrokers... Ich NAT ja von Extren(öffentlich) auf die Interne Farm IP und der Sessionbroker ist ja auf dem Ersten DC installiert.

    Montag, 12. Dezember 2011 14:14
  • Bevor du ein VPN probierst, empfehle ich dir doch ein RD-GW aufzubauen. Es ist nicht schwer. Noch einfacher ist es, wenn du eine Unternehmenszertifizierungsstelle hast. Dann hast du nicht die Probleme mit selbst signierten Zertifikaten.

    Client muss in mstsc das RD-GW angegeben haben. Baut HTTPS zum RD-GW auf. Dort entscheidet eine CAP, ob aufs GW zugegriffen werden darf. Wenn ja, entscheidet eine RAP, auf welche Farm zugegriffen werden darf. Zwischen dem GW und der Farm wird RDP benutzt.

    Eine detaillierte Anleitung findest du im Technet unter Schrittweise Anleitung zum Bereitstellen von Remotedesktopgateway.

    Nochmal zu Namensauflösung (sorry, ich bin hartnäckig, aber meist liegt es daran). Kannst du die in meinem letzten Post gestellten Fragen alle ausschließen?

    Montag, 12. Dezember 2011 14:46
  • Ok ich probier es mal meine frag ist ja eher warum wurde das system nicht gleich mit RD-GW eingerichtet ... CA habe ich leider in der Umgebung nicht :(

     

    und die Namesauflösung Intern ist ja sauber und die Extrene (öffentliche Adresse) für NAT, ist nur eine IP ohne Namen und ist auch von intern auch überall angepingt werden und auch von jedem Extrene PC wo ich es probiert habe... und ich komm ja auch immer bis zum Anmeldefenster die Fehlermeldung kommt ja erst nach dem Anmeldeversuch :(

    Montag, 12. Dezember 2011 15:29
  • warum wurde das system nicht gleich mit RD-GW eingerichtet

    Weil es vielleicht ein gewachsenes System ist und es unter 2003 noch kein solches Gateway gab?

    Oder weil der, der es eingerichtet hat, nicht wusste, was ein solches Gateway macht?

    Oder weil er sich der Konfiguration nicht sicher war?

    Oder ...

    ... CA habe ich leider in der Umgebung nicht :(

     

    die Extrene (öffentliche Adresse) für NAT, ist nur eine IP ohne Namen

    Dann wirst du Probleme mit dem Zertifikat bekommen. Die selbst signierten Zertifikate sind auf den Rechnernamen ausgestellt. Wenn der Client dann eine IP-Adresse eingibt, stimmt die nicht mit dem Common Name des Zertifikats überein und es kommt zum Fehler.

    und ich komm ja auch immer bis zum Anmeldefenster die Fehlermeldung kommt ja erst nach dem Anmeldeversuch :(

    Das ist normal (Authentifizierung auf Netzwerkebene). Wenn das Anmeldefenster kommt, besteht noch gar keine Verbindung.

    Montag, 12. Dezember 2011 16:35
  • Wollte nur mal kurze zwischen Meldung, habe das gleich nochmal in na Testumgebung aufgebaut und da funktioniert es meine Vermutung ist nun das das Nat Problem macht!
    Montag, 19. Dezember 2011 09:02
  • ok NAT ist wohl auch nicht schuld :(
    Montag, 19. Dezember 2011 09:58
  • Welche Adresse "nattest" du?

    Welchen Clusterausführungsmodus verwendest du und wie viele Netzwerkkarten haben die Knoten?

    Welche Affinität hast du gewählt?

    Hast du auf allen Remotedesktop-Sitzungshosts den gleichen Farmnamen verwandt (keine Tippfehler)?

     

    Montag, 19. Dezember 2011 11:09
  • Es gibt nen Static auf jede Interne Addresse.

     

    Clustermodus ist im Multicast. alle Server haben eine Netzwerkkarte.

    Wo wähle ich nochmal die Affinität aus?

    Und der Name ist überall gleich...

     

    Denk bitte dran das es Intern keine Probleme gibt ;) halt nur wenn ich von extren komme!

     


    • Bearbeitet fragger85 Montag, 19. Dezember 2011 13:56
    Montag, 19. Dezember 2011 13:56
  • Es gibt nen Static auf jede Interne Addresse.

    Was bedeutet das?

    Du hast eine Clusteradresse. Und nur die wollen die Clients erreichen, also muss die im NAT-Router eingetragen sein.

    Wo wähle ich nochmal die Affinität aus?

    Im Einstellungsdialog der Portregel.

    Alle Fragen, die ich gestellt habe, haben etwas mit temporären Effekten zu tun. Und solche hast du doch, oder?

    Montag, 19. Dezember 2011 14:58
  •  

    Das für jede Adresse eine NAT- Regel eingestellt ist! also für jede Interne eine Öffentliche Adresse für Port 3389.

     

    keine Affinität

     

    ja das Problem ist immer nur temporärer Effekt

     

     

     

    Montag, 19. Dezember 2011 15:25
  • Achso witzig ist ja auch das ich die Umgebung ja nachgebaut habe und das funktioniert da alles ohne Probleme ...

    • Bearbeitet fragger85 Montag, 19. Dezember 2011 15:55
    Montag, 19. Dezember 2011 15:29
  •  

    Das für jede Adresse eine NAT- Regel eingestellt ist! also für jede Interne eine Öffentliche Adresse für Port 3389.


    Warum ist das so? Das ist doch unnötig!

    Und mit welcher Adresse versuchen sich die Clients zu verbinden?

    Montag, 19. Dezember 2011 16:37
  • so unnötig ist das nicht da ohne dieses Static keiner ins internet kommt. hab aber gerade nen system logs nachgeguckt!

     

    Log 1:

    Der Remotedesktop-Verbindungsbroker hat eine Verbindungsanforderung für Benutzer Domain\testuser empfangen.

    Hinweise in der RDP-Datei (TSV-URL) = tsv://MS Terminal Services Plugin.1.MSP-TER
    Ursprüngliche Anwendung = 
    Der Aufruf stammt vom Umleitungsserver = Computername.domain.local
    Der Redirector ist konfiguriert als Farm member.

    Log 2:

    Der Endpunkt für diese Verbindungsanforderung wurde vom Remotedesktop-Verbindungsbroker erfolgreich bestimmt.
    Endpunktname = MSP-TER
    Endpunkttyp = Farm
    Name des Ressourcen-Plug-Ins = MS Terminal Services Plugin.

    Log 3:

    Vom Remotedesktop-Verbindungsbroker wurde die Verbindungsanforderung für Benutzer Domain\testuser erfolgreich verarbeitet. Umleitungsinformationen:
    Zielname = TS2
    Ziel-IP-Adresse = 10.235.177.15
    Ziel-NetBIOS-Adresse = Computername
    Ziel-FQDN = TS2.Domain.local
    Getrennte Sitzung gefunden = 0x0.

     

    Log 4:

    Ein Kerberos-Dienstticket wurde angefordert.

    Kontoinformationen:
        Kontoname:        Testuser@Domain.LOCAL
        Kontodomäne:        Domain.LOCAL
        Anmelde-GUID:        {c7be14f2-395c-4e7d-697b-36cd1109540e}

    Dienstinformationen:
        Dienstname:        TS2
        Dienst-ID:        Domain\TS2

    Netzwerkinformationen:
        Clientadresse:        ::ffff:10.248.177.14
        Clientport:        64183

    Weitere Informationen:
        Ticketoptionen:        0x40810000
        Ticketverschlüsselungstyp:    0x12
        Fehlercode:        0x0
        Übertragene Dienste:    -

    Dieses Ereignis wird jedes Mal generiert, wenn der Zugriff auf eine Ressource angefordert wird, z. B. auf einen Computer oder einen Windows-Dienst. Der Dienstname steht für die Ressource, auf die der Zugriff angefordert wurde.

    Dieses Ereignis kann mit Windows-Anmeldeereignissen korreliert sein, wenn Anmelde-GUID-Felder in jedem Ereignis verglichen werden.  Das Anmeldeereignis findet auf dem Computer statt, auf den zugegriffen wird, d.h. oft einem anderen Computer als dem Domänencontroller, auf dem das Dienstticket ausgestellt wurde.

    Ticketoptionen, Verschlüsselungstypen und Fehlercodes sind in RFC 1510 definiert.

    Log 5:

    Ein Konto wurde abgemeldet.

    Antragsteller:
        Sicherheits-ID:        Domain\DC-02$
        Kontoname:        DC-02$
        Kontodomäne:        Domain
        Anmelde-ID:        0x1cb886a8

    Anmeldetyp:            3

    Dieses Ereignis wird generiert, wenn eine Anmeldesitzung zerstört wird. Es kann anhand des Wertes der Anmelde-ID positiv mit einem Anmeldeereignis korreliert werden. Anmelde-IDs sind nur zwischen Neustarts auf demselben Computer eindeutig.

     

    kann es sein das Beim Anmelden der Fehler von Kerb. oder so abgebrochen wird?

    Nur warum kommt die Meldung das der Remotecomputer nicht erreichbar wäre ?

     

     

     

     

     

     

     

    Montag, 19. Dezember 2011 16:49
  • Warum keiner ins Internet kommen soll ist mir nicht klar. Dafür braucht man doch im NAT-Router keine Adresszuordnung, da das doch die eigentliche Aufgabe von NAT ist.

    Ich kann in deinem Log die Meldung nicht finden, dass der Remotecomputer nicht erreichbar wäre.

    Die Log-Einträge sind alle normal. Auch bei Kerberos sehe ich keine Probleme. Der testuser hat sich am DC angemeldet, ein Ticket bekommen, und der TS fordert dies an.

    Merkwürdig ist lediglich die Client-Adresse. Solche Adressen werden nur von Dual-Stack-Komponenten verwendet. Der Client müsste aber über Teredo hereinkommen!

    Wie ist denn der Netzwerkweg vom Client bis zum Remotedesktop-Sitzungshost?

    Montag, 19. Dezember 2011 17:04
  •  

    Sorry für die schnelle Zeichnung mit Paint ;) Fals Fragen sind frag ;)

    Dienstag, 20. Dezember 2011 09:03
  • der Strich ist die Firewall ;)
    Dienstag, 20. Dezember 2011 09:53
  • Danke für die Zeichnung. Aber die IP-Adressen stimmen nicht mit den im Log aufgezeichneten Daten überein.

    Laut Log hat der Client ::ffff:10.248.177.14. Aus deiner Zeichnung ist die interne IP der Firewall / des NAT-Routers nicht ersichtlich. Laut Zeichnung ist es aber ein XP-Client. Der verwendet nicht IPv6 oder hat du das extra aktiviert? Wenn ja bitte deaktivieren, um es als Fehlerquelle auszuschließen. Oder setzt die Firewall das etwa in IPv6 um?

    Laut Log ist die Adresse von TS2 10.235.177.15, in deiner Zeichnung 10.200.140.14.

    Ich hoffe, du verwendest überall einen 8er Suffix (also 255.0.0.0).

    Siehst du Unterschiede im Log, wenn eine Verbindung hergestellt werden kann und wenn nicht?



    • Bearbeitet mslux Dienstag, 20. Dezember 2011 10:16
    Dienstag, 20. Dezember 2011 10:14
  • die IP's in der Zeichnung sind frei erfunden. Und im Log habe ich natürlich vorher andere IP's rein geschrieben. Ist ja schließlich eine Liveumgebung :)

    und richtige Subnet sind sie auch alle.

     

    Ich werde mal das IPv6 abstellen denke aber nich das da der fehler liegt! IPv6 hab ich ja in meiner Umgebung auch angelassen.


    • Bearbeitet fragger85 Dienstag, 20. Dezember 2011 14:54
    Dienstag, 20. Dezember 2011 14:52
  • Gerade test ohne IPv6 gemacht gleich problem wie vorher :(
    Dienstag, 20. Dezember 2011 15:00
  • Wie soll man dir helfen, wenn du die Daten hier im Forum frei erfindest? Vielleicht ist auch dein Problem frei erfunden?

    Es wird schon einen Grund haben, warum in diesem Thread noch kein anderer als ich geantwortet hat.

    Da du nicht einmal alle meine Fragen beantwortest, stelle ich hiermit mein Engagement ein.

    Schade für die aufgewendete Zeit!
    • Bearbeitet mslux Dienstag, 20. Dezember 2011 15:09
    Dienstag, 20. Dezember 2011 15:08
  • das Produktives Netz! also werd ich ja wo Teufel tun die Öffentlichen Addressen hier Preis zu geben sind ja leider nicht nur liebe user im Netz unterwegs!

    Wieso sollte ich dieses Problem frei erfinden?

    und auf welche Frage hab ich denn nicht geantwortet ??

    Dienstag, 20. Dezember 2011 15:24
  • achso und PS bis auf die IP's und die Domain ist hier auch nix verändert an dem konstrukt!!
    Dienstag, 20. Dezember 2011 15:28
  • So habe das Problem lösen können habe ein TS-Gateway aufgestellt und damit funktioniert der zugriff problemlos.

    Habe jetzt nur noch ein Problem und zwar mit der Passwortänderung wenn es abgelaufen ist. Intern klappt es ohne Problem nur wenn jetzt der User von Außen aufgeforder wird das Passwort zu ändern kriegt er immer die Meldung das es kein Komplexe  Passwort wäre. Obwohl es das aufjedenfall ist weil ich Selber per Teamviewer ein Komplexes Passwort eingegeben habe und auch keins was Vorher schon benutzt wurde. Es hatte 12 Zeichen a 3 Sonderzeichen, 4 Zahlen , ein Großbuchstaben und der Rest kleine.

    Kennt einer das Problem vielleicht auch und hat eine Lösung? Liegt es vielleicht an der Gateway Authentifizierung ?


    • Bearbeitet fragger85 Donnerstag, 5. April 2012 14:41
    Donnerstag, 5. April 2012 14:39