9
RDP-Probleme seit upgrade auf WIN10
moinmoin ...
... um's kurz zu erklären:
Ich habe hier einen PC im LAN von WIN 8.1 auf WIN 10 "upgegraded".
Augenscheinlich lief das relativ sauber durch.
Aktuell einziges und gravierendes Problem:
Die Verbindung zu unserem Terminal-Server reisst immer ab und wird nach einigen Sekunden automatisch neu verbunden.
Das Problem besteht nur, wenn der Zugriff durch den VPN-Tunnel erfolgt!
Ich habe testweise mal an der Firewall des "normalen" DSL Anschlusses RDP an den Terminal-Server erlaubt.
Auf dem Wege klappt es ohne Aussetzer.
Auch der Zugriff auf einen anderen externen Terminal-Server klappt einwandfrei.
Irgendwie scheint es am Tunnel zu liegen.
Alle anderen Clients mit WIN7 bzw. WIN 8.1 haben keine Probleme.
Der WIN10-PC befindet sich in Standort A, der Terminalserver (2008R2) in Standort B.
Verbunden sind die beiden Niederlsasungen über einen IPsec-Tunnel mit LANCOM 1721 - Routern.
Als Leitung steht je Standort eine SDSL 2MBit für das VPN bereit.
Vor dem Upgrade lief auch auf diesem PC alles sauber.
Was mich wundert: Müssten die Verbindungsabrisse nicht irgendwo im Log stehen?
Vielleicht hatte ja schon jemand mit diesem Phänomen zu kämpfen und kann mir einen "Wink mit der Raketenstütze" geben.
greetz
Der Rico
... um's kurz zu erklären:
Ich habe hier einen PC im LAN von WIN 8.1 auf WIN 10 "upgegraded".
Augenscheinlich lief das relativ sauber durch.
Aktuell einziges und gravierendes Problem:
Die Verbindung zu unserem Terminal-Server reisst immer ab und wird nach einigen Sekunden automatisch neu verbunden.
Das Problem besteht nur, wenn der Zugriff durch den VPN-Tunnel erfolgt!
Ich habe testweise mal an der Firewall des "normalen" DSL Anschlusses RDP an den Terminal-Server erlaubt.
Auf dem Wege klappt es ohne Aussetzer.
Auch der Zugriff auf einen anderen externen Terminal-Server klappt einwandfrei.
Irgendwie scheint es am Tunnel zu liegen.
Alle anderen Clients mit WIN7 bzw. WIN 8.1 haben keine Probleme.
Der WIN10-PC befindet sich in Standort A, der Terminalserver (2008R2) in Standort B.
Verbunden sind die beiden Niederlsasungen über einen IPsec-Tunnel mit LANCOM 1721 - Routern.
Als Leitung steht je Standort eine SDSL 2MBit für das VPN bereit.
Vor dem Upgrade lief auch auf diesem PC alles sauber.
Was mich wundert: Müssten die Verbindungsabrisse nicht irgendwo im Log stehen?
Vielleicht hatte ja schon jemand mit diesem Phänomen zu kämpfen und kann mir einen "Wink mit der Raketenstütze" geben.
greetz
Der Rico
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 292360
Url: https://administrator.de/forum/rdp-probleme-seit-upgrade-auf-win10-292360.html
Ausgedruckt am: 26.12.2024 um 00:12 Uhr
9 Kommentare
Neuester Kommentar
Hallo,
Schau doch rein, beim LANCOM. Oder nimm ein Wireshark.....
Gruß,
Peter
Schau doch rein, beim LANCOM. Oder nimm ein Wireshark.....
kann mir einen "Wink mit der Raketenstütze" geben.
Mir fällt jetzt Spontan nur der Treiber deine LAN Hardware ein. Ist denn an diesen Rechner alles für Windows 10 freigegeben? Mal eine neu Installation mit Windows 10 versucht?Gruß,
Peter
Ich muss gestehen: Ich hab von den LANCOM Routern keine Ahnung ...
Die wurden als "Business VPN" der Telekom vor ein paar Jahren integriert ...
Wir hatten da schon einmal eine Frage zu. Da hieß es beim Rosa T: 1721? supporten wir nicht mehr ...
Und das war ca. 2 Jahre nach der Einrichtung ...
Und ja ... Windows 10 ist auf diesem PC bereits einmal neu installiert worden.
Greetz
Der Rico
Die wurden als "Business VPN" der Telekom vor ein paar Jahren integriert ...
Wir hatten da schon einmal eine Frage zu. Da hieß es beim Rosa T: 1721? supporten wir nicht mehr ...
Und das war ca. 2 Jahre nach der Einrichtung ...
Und ja ... Windows 10 ist auf diesem PC bereits einmal neu installiert worden.
Greetz
Der Rico
Moin,
also wenn andere Clients kein Problem haben und der Tunnel von den LANCOM's aufgebaut wird kann es doch eigentlich nicht am Tunnel liegen?
Ich würde mal mit den Einstellungen/Eigenschaften des mstsc am Client "spielen".
Henning
also wenn andere Clients kein Problem haben und der Tunnel von den LANCOM's aufgebaut wird kann es doch eigentlich nicht am Tunnel liegen?
Ich würde mal mit den Einstellungen/Eigenschaften des mstsc am Client "spielen".
Henning
An den Client-Settings lag's auch nicht ...
Aber am Server! Es war der einzige Server, der das optional Update für RDP noch nicht drauf hatte ...
Scheint nun zu klappen ...
Aber am Server! Es war der einzige Server, der das optional Update für RDP noch nicht drauf hatte ...
Scheint nun zu klappen ...
Hallo,
Gruß,
Peter
Zitat von @RicoPausB:
Aber am Server! Es war der einzige Server, der das optional Update für RDP noch nicht drauf hatte ...
Es wäre nett wenn du auch für andere hier noch das optionale Update benennen könntest.Aber am Server! Es war der einzige Server, der das optional Update für RDP noch nicht drauf hatte ...
Gruß,
Peter
Das war's dann leider doch wohl noch nicht.
Die Verbindungsabbrüche bestehen weiterhin ...
Jetzt habe ich aber wenigstens mal ein Log!
Die Ereignis-ID 4105 wird angezeigt.
Der Lizenzserver ist ein Mitgliedsserver und Mitglied der Gruppe Terminal-Lizensierungsserver.
Sonst würde das Problem wohl auch bei anderen usern auftreten.
Die Verbindungsabbrüche bestehen weiterhin ...
Jetzt habe ich aber wenigstens mal ein Log!
Die Ereignis-ID 4105 wird angezeigt.
Protokollname: System
Quelle: Microsoft-Windows-TerminalServices-Licensing
Datum: 11.01.2016 08:51:25
Ereignis-ID: 4105
Aufgabenkategorie:Keine
Ebene: Warnung
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: SRVTSWAL.mydomain.lan
Beschreibung:
Der Remotedesktop-Lizenzserver kann die Lizenzattribute für Benutzer "rpatzke" in der Active Directory-Domäne "mydomain.lan" nicht aktualisieren. Stellen Sie sicher, dass das Computerkonto für den Lizenzserver Mitglied der Gruppe "Terminalserver-Lizenzserver" in der Active Directory-Domäne "mydomain.lan" ist.
Falls der Lizenzserver auf einem Domänencontroller installiert ist, muss das Netzwerkdienstkonto ebenfalls Mitglied der Gruppe "Terminalserver-Lizenzserver" sein.
Fügen Sie in diesem Fall zunächst die entsprechenden Konten zur Gruppe "Terminalserver-Lizenzserver" hinzu, und starten Sie anschließend den Remotedesktop-Lizenzierungsdienst neu, um die Verwendung von benutzergebundenen Remotedesktopdienste-Clientzugriffslizenzen zu verfolgen bzw. Berichte darüber zu erstellen.
Win32-Fehlercode: 0x80070005
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-TerminalServices-Licensing" Guid="{4D99F017-0EB1-4B52-8419-14AEBD13D770}" EventSourceName="TermServLicensing" />
<EventID Qualifiers="51456">4105</EventID>
<Version>0</Version>
<Level>3</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2016-01-11T07:51:25.000000000Z" />
<EventRecordID>126532</EventRecordID>
<Correlation />
<Execution ProcessID="0" ThreadID="0" />
<Channel>System</Channel>
<Computer>SRVTSWAL.mydomain.lan</Computer>
<Security />
</System>
<UserData>
<EventXML xmlns:auto-ns3="http://schemas.microsoft.com/win/2004/08/events" xmlns="Event_NS">
<param1>rpatzke</param1>
<param2>mydomain.lan</param2>
<param3>0x80070005</param3>
</EventXML>
</UserData>
</Event>Der Lizenzserver ist ein Mitgliedsserver und Mitglied der Gruppe Terminal-Lizensierungsserver.
Sonst würde das Problem wohl auch bei anderen usern auftreten.
Das hier habe ich nun auch eingerichtet ...
Aber die Meldung bleibt auch nach Replikation und nach Neustart der Terminal-Lizensierungsdienste noch bestehen.
Aber die Meldung bleibt auch nach Replikation und nach Neustart der Terminal-Lizensierungsdienste noch bestehen.
Und auch #discuss das hier brachte nicht den gewünschten Erfolg ...
Die Abrisse finden weiterhin im Takt von 53/54 Sek statt ...
Die Abrisse finden weiterhin im Takt von 53/54 Sek statt ...
Man mag es kaum glauben ...
Aber der PC hatte im Netzwerk- und Freigabe-Center als Netzwerktyp noch "öffentlich" stehen!
Nach dem Wechsel auf "Privat" läuft alles wie gewohnt ...
Würde also sagen "SOLVED" ;)
greetz
Der Rico
Aber der PC hatte im Netzwerk- und Freigabe-Center als Netzwerktyp noch "öffentlich" stehen!
Nach dem Wechsel auf "Privat" läuft alles wie gewohnt ...
Würde also sagen "SOLVED" ;)
greetz
Der Rico
