14
Windows 8.1 RDP-Client - verzögerter Zugriff auf Server 2003 - 2008R2.
Hallo liebe Mitstreiter,
nun habe ich auch mal ein Problem, dessen Ursache wohl am neuen Design des RDP-Protokoll begründet ist oder schlicht ein Bug ist.
Ich benutze für die Wartung gern den Adminzugang per RDP-Console. Das mach ich seit Jahren genau so. Leider ist mit der Einführung von Windows 8.1 der Zugriff per RDP von selbigen aus, auf alle Windows-Server, mit Ausnahme der 2012er, etwa 300ms verzögert. Mache ich das von einem Window 7 oder XP aus, funktioniert es tadellos.
Hat jemand eine Idee wie oder wo ich was ändern könnte, damit ich alle Server wieder Nervenstrapaze bedienen kann?
Juppeck
nun habe ich auch mal ein Problem, dessen Ursache wohl am neuen Design des RDP-Protokoll begründet ist oder schlicht ein Bug ist.
Ich benutze für die Wartung gern den Adminzugang per RDP-Console. Das mach ich seit Jahren genau so. Leider ist mit der Einführung von Windows 8.1 der Zugriff per RDP von selbigen aus, auf alle Windows-Server, mit Ausnahme der 2012er, etwa 300ms verzögert. Mache ich das von einem Window 7 oder XP aus, funktioniert es tadellos.
Hat jemand eine Idee wie oder wo ich was ändern könnte, damit ich alle Server wieder Nervenstrapaze bedienen kann?
Juppeck
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: 244159
Url: https://administrator.de/contentid/244159
Ausgedruckt am: 04.12.2024 um 08:12 Uhr
14 Kommentare
Neuester Kommentar
Moin.
300ms strapazieren dein Nervenkostüm?!?
Schalte die "Authentifizierung auf Netzwerkebene" ab, dann gehts schneller. Und die Sicherheitslücke gibts gratis dazu.
Cheers,
jsysde
300ms strapazieren dein Nervenkostüm?!?
Schalte die "Authentifizierung auf Netzwerkebene" ab, dann gehts schneller. Und die Sicherheitslücke gibts gratis dazu.
Cheers,
jsysde
etwa 300ms verzögert
Da hat wohl einer zu viel Ecstasy geschluckt 
Stell deine Maus-DPI Einstellungen einfach höher dann hast du diesen "massiven" Zeitverlust sofort wieder drin ... duck und wegGrüße @colinardo
1
Wenn man eine Zeile schreiben will und dabei jedes Zeichen mit einer Delay von 300ms angezeigt wird, hat dass mit flüssig nicht mehr viel zutun.
Die Sicherheitslücke mag ein Problem sein, wenn die Maschine einen Link ins Internet oder sonst wo, hätte - haben die Maschinen nicht und würde auch nur dann ein Problem sein, wenn man Terminal-Server Dienste anbieten wollte - ich nutze es nur zur Administration. Die 2003R2 hatten dieses Feature gar nicht und waren auch problemlos 10 Jahre alt geworden. Danke jedoch für den Hinweis und den Tipp. Ich werde es kommende Woche sofort probieren ob das Problem damit erledigt ist. Einige Andere vermuteten dass es mit dem neuen Caching zusammen hängen könnte. Potential hätte auch dieser Ansatz.
Danke de Juppeck
Die Sicherheitslücke mag ein Problem sein, wenn die Maschine einen Link ins Internet oder sonst wo, hätte - haben die Maschinen nicht und würde auch nur dann ein Problem sein, wenn man Terminal-Server Dienste anbieten wollte - ich nutze es nur zur Administration. Die 2003R2 hatten dieses Feature gar nicht und waren auch problemlos 10 Jahre alt geworden. Danke jedoch für den Hinweis und den Tipp. Ich werde es kommende Woche sofort probieren ob das Problem damit erledigt ist. Einige Andere vermuteten dass es mit dem neuen Caching zusammen hängen könnte. Potential hätte auch dieser Ansatz.
Danke de Juppeck
Na ja, ich gehöre der Generation der "Silver-Surfer" an und hab mit dem modernen Zeug wenig am Hut 
XTC und andere BTM überlasse ich gern der "Jung and modern People" Generation.
XTC und andere BTM überlasse ich gern der "Jung and modern People" Generation.Zitat von @juppeck:
Wenn man eine Zeile schreiben will und dabei jedes Zeichen mit einer Delay von 300ms angezeigt wird, hat dass mit flüssig
nicht mehr viel zutun.
gut, das konnten wir nicht ahnen, wir dachten eher an eine Login-Verzögerung Wenn man eine Zeile schreiben will und dabei jedes Zeichen mit einer Delay von 300ms angezeigt wird, hat dass mit flüssig
nicht mehr viel zutun.
Dann würde ich hier mal in Kombination mit Process-Monitor und Process-Explorer versuchen den Engpass bzw. Delay zu identifizieren.
http://serverfault.com/questions/332622/find-out-the-bottleneck-for-win ...
Moin.
Es geht bei der Authentifizierung auch innerhalb des LANs darum, dass keine (Admin-)Passwörter bei der RDP-Anmeldung abgegriffen werden können....
back2topic:
Ich nutze RDP ebenfalls schon seit ner Ewigkeit, mittlerweile auch von einem Windows 8.1 aus und kann dein Problem nicht nachvollziehen oder reproduzieren. Dabei spielt es keine Rolle, auf welches Server-OS ich zugreife: 2003/r2, 2008/r2, 2012/r - funktioniert bei allen völlig stressfrei. Ich nutze für RDP-Zugriffe entweder direkt die mstsc.exe oder eben den Remote Desktop Connection Manager von MS.
Hast du eine spezielle Software für die RPD-Nutzung/-Verwaltung oder rufst du einfach die mstsc.exe auf?
Cheers,
jsysde
Zitat von @juppeck:
Wenn man eine Zeile schreiben will und dabei jedes Zeichen mit einer Delay von 300ms angezeigt wird, hat dass mit flüssig
nicht mehr viel zutun.
Jetzt hab ich's kapiert. Las sich im Eingangsposting so, als würde das nur beim Anmelden passieren, daher auch mein Hinweis auf die Authentifizierung.Wenn man eine Zeile schreiben will und dabei jedes Zeichen mit einer Delay von 300ms angezeigt wird, hat dass mit flüssig
nicht mehr viel zutun.
Die Sicherheitslücke mag ein Problem sein, wenn die Maschine einen Link ins Internet oder sonst wo
Warum glaubt jeder, das Sicherheitslücken nur entstehen, wenn "die Maschine im Internet hängt"?Es geht bei der Authentifizierung auch innerhalb des LANs darum, dass keine (Admin-)Passwörter bei der RDP-Anmeldung abgegriffen werden können....
back2topic:
Ich nutze RDP ebenfalls schon seit ner Ewigkeit, mittlerweile auch von einem Windows 8.1 aus und kann dein Problem nicht nachvollziehen oder reproduzieren. Dabei spielt es keine Rolle, auf welches Server-OS ich zugreife: 2003/r2, 2008/r2, 2012/r - funktioniert bei allen völlig stressfrei. Ich nutze für RDP-Zugriffe entweder direkt die mstsc.exe oder eben den Remote Desktop Connection Manager von MS.
Hast du eine spezielle Software für die RPD-Nutzung/-Verwaltung oder rufst du einfach die mstsc.exe auf?
Cheers,
jsysde
Wenn das auch mit sauberen Installationen (nichts drauf, außer Windows) so ist, dann schalte MS ein. Ich denke jedoch, dass es nicht so ist, da wir auch 8.1er haben und ich damit keinen Unterschied feststellen konnte, egal, welche Serverversion (2003/08/08R2/12/12R2 - alle problemlos).
Zitat von @jsysde:
Moin.
> Zitat von @juppeck:
>
> Wenn man eine Zeile schreiben will und dabei jedes Zeichen mit einer Delay von 300ms angezeigt wird, hat dass mit
flüssig nicht mehr viel zutun.
Moin.
> Zitat von @juppeck:
>
> Wenn man eine Zeile schreiben will und dabei jedes Zeichen mit einer Delay von 300ms angezeigt wird, hat dass mit
flüssig nicht mehr viel zutun.
Beim Anmelden schreibe ich keinen Zeilenlänge Logon's
Warum glaubt jeder, das Sicherheitslücken nur entstehen, wenn "die Maschine im Internet hängt"?
Nun bin ich nicht Jeder und zum Anderen, weil Du keinen Zugang zu unserem Netzwerk bekommen kannst, um einen Sniffer o.ä.einsetzen zu können - was Grundvoraussetzung wäre.
back2topic:
Eine gute Idee, ich folge ihr..Ich nutze RDP ebenfalls schon seit ner Ewigkeit, mittlerweile auch von einem Windows 8.1 aus und kann dein Problem nicht
nachvollziehen oder reproduzieren. Dabei spielt es keine Rolle, auf welches Server-OS ich zugreife: 2003/r2, 2008/r2, 2012/r -
funktioniert bei allen völlig stressfrei. Ich nutze für RDP-Zugriffe entweder direkt die mstsc.exe oder eben den Remote
Desktop Connection Manager von MS.
Hast du eine spezielle Software für die RPD-Nutzung/-Verwaltung oder rufst du einfach die mstsc.exe auf?
nachvollziehen oder reproduzieren. Dabei spielt es keine Rolle, auf welches Server-OS ich zugreife: 2003/r2, 2008/r2, 2012/r -
funktioniert bei allen völlig stressfrei. Ich nutze für RDP-Zugriffe entweder direkt die mstsc.exe oder eben den Remote
Desktop Connection Manager von MS.
Hast du eine spezielle Software für die RPD-Nutzung/-Verwaltung oder rufst du einfach die mstsc.exe auf?
Nein, ich benutze MSTSC.exe auf dem jeweiligen Rechner. Ja, es ist egal, ob ich Domänenmitglied bin oder nicht. Es spielt auch keine Rolle
ob der PC schon etwas installiert ist, oder nicht. Und nochmal nein, es ist nicht nur bei mir so, auch von anderen Admins habe ich sowas schon gehört.
Über das Problem habe ich schon mal gelesen, leider habe ich es nicht gespeichert. Ich erinnere mich nur noch daran, dass es was mit dem Caching von RDP zutun haben soll. Ich habe dass Problem auch erst mit Windows 8.1 bekommen. In Windows 8.0 konnte ich noch flüssig arbeiten. Windows 7 hatte dieses Problem auch, konnte dort aber den älteren RDP-Client nutzen und damit war das Problem eben keines mehr.
Fremdprodukte habe ich nie probiert (wenn man den o.g. Client aus dem Sever 2003R2 vernachlässig) denn erstens kosten die Geld oder sind potentiell unsicher, da deren Herkunft und Geschichte unbekannt sind. Ich erkenne auch kein Sinn darin, Fremdprodukte einsetzten zu wollen, um eine Grundfunktionalität nutzen zu können die von MS bereits mitgeliefert wird.
Ich möchte noch eine Beobachtung ergänzen, die ich bisher unerwähnt lies. Das Aktualisieren des Client-Bildschirms geht ruckartig und nach den ca. 250-300ms sehr schnell. Die Prozessauslastung ist auf dem Client kaum anzeigbar. Ich hab jetzt keine Zeit für Netzwerkanalysen um zu schauen, wie das Verhalten des gesendeten und empfangen Daten zwischen Server und Client im Vergleich zum XP RDP-Client ist.
Für Ideen wäre ich sehr empfänglich und das Problem und dessen Ursache würde ich auch gern wissen. Auf den erhobenen Sicherheitszeigefinger würde hingegen gern verzichten. Ich bin lange genug im Geschäft (35Jahre) um abwägen zu können, was einsetzbar ist und was man besser verzichtet. Ich bin mir recht
sicher, dass es eine Lösung gibt bzw. eine Ursache, die mich sehr interessiert.
Juppeck
Hallo.
Hab' jetzt auf die schnelle ein paar Möglichkeiten gefunden (Google), woran das unter Windows 8.1 vielleicht liegen könnte:
- der oder die Switche können nicht richtig mit Windows 8.1 (dritter Treffer bei Google, kommt mir aber merkwürdig bzw. ausgeschlossen vor)
- auf ganz wenigen Webseiten wird beschrieben, daß RDP unter W8.1 dann langsam ist, wenn das Update 1 (aus April) nicht installiert ist, das OS sollte also auf Stand 8.1.1. sein , danach sind die Probleme verschwunden
- manchen hat ein neuer Grafiktreiber für den Host geholfen (kommt mir auch merkwürdig vor, RDP interessiert das Grafiksystem am Host eigentlich überhaupt nicht, es sei denn, es wird RemoteFX eingesetzt)
- manchen half es, Remote FX zu deaktivieren
- anderen hat es wiederum geholfen, die Grafiktreiber am zugreifenden Client zu aktualisieren
- bei manchen war ein TrendMicro Virenscanner ("OfficeScan") der Schuldige, TrendMicro hat danach einen Patch herausgebracht
- hier und da war trotz Update auf 8.1.1 immer noch schlechte RDP-Performance, die hatten aber keine Folgepatches zu 8.1.1 installiert, danach ging's besser
- manchen haben diese beiden Updates gefehlt: http://support.microsoft.com/kb/2883200 und http://support.microsoft.com/kb/2884846
Grüße
von
departure
Hab' jetzt auf die schnelle ein paar Möglichkeiten gefunden (Google), woran das unter Windows 8.1 vielleicht liegen könnte:
- der oder die Switche können nicht richtig mit Windows 8.1 (dritter Treffer bei Google, kommt mir aber merkwürdig bzw. ausgeschlossen vor)
- auf ganz wenigen Webseiten wird beschrieben, daß RDP unter W8.1 dann langsam ist, wenn das Update 1 (aus April) nicht installiert ist, das OS sollte also auf Stand 8.1.1. sein , danach sind die Probleme verschwunden
- manchen hat ein neuer Grafiktreiber für den Host geholfen (kommt mir auch merkwürdig vor, RDP interessiert das Grafiksystem am Host eigentlich überhaupt nicht, es sei denn, es wird RemoteFX eingesetzt)
- manchen half es, Remote FX zu deaktivieren
- anderen hat es wiederum geholfen, die Grafiktreiber am zugreifenden Client zu aktualisieren
- bei manchen war ein TrendMicro Virenscanner ("OfficeScan") der Schuldige, TrendMicro hat danach einen Patch herausgebracht
- hier und da war trotz Update auf 8.1.1 immer noch schlechte RDP-Performance, die hatten aber keine Folgepatches zu 8.1.1 installiert, danach ging's besser
- manchen haben diese beiden Updates gefehlt: http://support.microsoft.com/kb/2883200 und http://support.microsoft.com/kb/2884846
Grüße
von
departure
Departure69: Die Patches habe ich natürlich alle installiert, und da kommen einige nach dem Rollup1 im April.
Das Problem ist der Trendmicro Officescan, und den hatte ich gar nicht auf dem Radar - wieso auch. Nun hätte man drauf kommen können wenn man mal überlegt, dass der RDP ja ein Caching macht und ja auch die Zwischenablage zwischen den Host und dem Client tauschen könnte, was ich eigentlich als einiges der Optionen zulasse. Nun, das deaktivieren des OfficeScan alleine löst das Problem nicht sondern erst die Deinstallation schafft den gewünschten Effekt. So langsam nervt der Trend - erstens findet der nicht alles, zweitens macht er den Login recht lahm, und drittens kommt die deutsche Version immer erst 3-6 Monate später als die Englische. Das sagt schon was über die Kundenverbundenheit zu Europäern aus. Im ersten Quartal den kommenden Jahres läuft der Scanner-Vertag aus und ich werde auf den ESET NOD32 umsteigen. Beim Googlen bin ich auf den Thread mit dem Officescan-Hinweis nicht gestoßen. Ich werde den Patch anfordern.
Die anderen Hinweise mit der Update-Arie von MS fand ich wie auch die auf die Grafiktreiber. Da aber andere Geräte mit unterschiedlichen Grafikkarten ausgestattet waren, schloss ich sie aus.
Besten Dank für eure Hinweise und Bemühungen.
Juppeck
Das Problem ist der Trendmicro Officescan, und den hatte ich gar nicht auf dem Radar - wieso auch. Nun hätte man drauf kommen können wenn man mal überlegt, dass der RDP ja ein Caching macht und ja auch die Zwischenablage zwischen den Host und dem Client tauschen könnte, was ich eigentlich als einiges der Optionen zulasse. Nun, das deaktivieren des OfficeScan alleine löst das Problem nicht sondern erst die Deinstallation schafft den gewünschten Effekt. So langsam nervt der Trend - erstens findet der nicht alles, zweitens macht er den Login recht lahm, und drittens kommt die deutsche Version immer erst 3-6 Monate später als die Englische. Das sagt schon was über die Kundenverbundenheit zu Europäern aus. Im ersten Quartal den kommenden Jahres läuft der Scanner-Vertag aus und ich werde auf den ESET NOD32 umsteigen. Beim Googlen bin ich auf den Thread mit dem Officescan-Hinweis nicht gestoßen. Ich werde den Patch anfordern.
Die anderen Hinweise mit der Update-Arie von MS fand ich wie auch die auf die Grafiktreiber. Da aber andere Geräte mit unterschiedlichen Grafikkarten ausgestattet waren, schloss ich sie aus.
Besten Dank für eure Hinweise und Bemühungen.
Juppeck
@juppeck:
Freut mich, daß Du nun eine Lösung finden konntest.
Was mich allerdings etwas wundert: Ich habe auch TrendMicro im Einsatz, allerdings nicht OfficeScan, sondern die Worry-Free-Business-Security-Suite (WFBS). denke aber, die beiden Produkte sind im technischen Unterbau gleich. Ich habe zwar bisher nur einen einzigen Windows 8.1.1-Pro-Rechner im Einsatz, aber an diesem macht der RDP-Client keine Probleme, egal, auf welches Ziel ich gehe, und das Zwischencachen und die Zwischenablage sind auch aktiviert.
Dafür habe ich mit TrendMicro WFBS Probleme bei Fingerabdruckscannern, die vom Fat-Client unter Windows 7 in einen Citrix-Terminalserver eingeschleift werden, da mußte ich auch schon auf ein anderes Produkt ausweichen.
Möglicherweise macht TrendMicro bei RDP nur in speziellen Konstellationen Ärger, und eine solche scheint bei Dir vorzuliegen und bei mir scheinbar nicht, was auch immer genau der Unterschied nun wirklich sein mag.
ESET NOD32 ist sicherlich eine gute Entscheidung, liegt in den immer wieder mal erscheinenden Ranglisten zu Virenscannern meist auch oberhalb von TrendMicro.
Grüße
von
departure
Freut mich, daß Du nun eine Lösung finden konntest.
Was mich allerdings etwas wundert: Ich habe auch TrendMicro im Einsatz, allerdings nicht OfficeScan, sondern die Worry-Free-Business-Security-Suite (WFBS). denke aber, die beiden Produkte sind im technischen Unterbau gleich. Ich habe zwar bisher nur einen einzigen Windows 8.1.1-Pro-Rechner im Einsatz, aber an diesem macht der RDP-Client keine Probleme, egal, auf welches Ziel ich gehe, und das Zwischencachen und die Zwischenablage sind auch aktiviert.
Dafür habe ich mit TrendMicro WFBS Probleme bei Fingerabdruckscannern, die vom Fat-Client unter Windows 7 in einen Citrix-Terminalserver eingeschleift werden, da mußte ich auch schon auf ein anderes Produkt ausweichen.
Möglicherweise macht TrendMicro bei RDP nur in speziellen Konstellationen Ärger, und eine solche scheint bei Dir vorzuliegen und bei mir scheinbar nicht, was auch immer genau der Unterschied nun wirklich sein mag.
ESET NOD32 ist sicherlich eine gute Entscheidung, liegt in den immer wieder mal erscheinenden Ranglisten zu Virenscannern meist auch oberhalb von TrendMicro.
Grüße
von
departure
@departure69:
Die Produkte von TrendMicro unterscheiden sich untereinander in den Versionen und der Zusammensetzung. Der Officescan war eine Version 10.6 in einer Enterprise Umgebung. Der Fehler tritt mit Version 11 nicht mehr auf - das RDP läuft wie gewohnt ohne Verzögerungen.
Nun, dafür funktioniert nun das Dashboard des Servers bzw. des Web-Portals nicht mehr. Die Jungs von TM haben doch glatt einfach den PHP samt Apache-Supportfiles fehlen lassen. Nun, ich habe ein Ticket aufgemacht und nun geht der Ärger erst richtig los. Eigentlich will ich nichts mehr daran machen - das Dashboard wäre zwar schön, aber schränkt mich erstmal nicht weiter ein. In 4 Monaten muss ich sowieso ein Upgrade Scenario des TM-OfficeScan machen denn Ende des ersten Quartal läuft der 3 Jahresvertrag. Ob ich die Zeit noch investieren will um das Dashboard mit Hilfe des Supports (der sehr träge ist) zu fixen, hab ich noch nicht entschieden. Es ist jedoch ein gutes Beispiel dafür, wie US-Konzerne im Ausland agieren. Die US-Fassung ist 4-6 Monate früher verfügbar als eine Deutsche Fassung und diese ist dann nicht mal fehlerfrei. Diesen PHP-Install Fehler schleppen die TM Leute schon seit wenigstens 2 Jahren mit sich rum und bekommen es nicht in den Griff. Nun, TrendMicro war mal recht gut, dass ist jedoch schon lange her. Meine eigenen Erfahrungen stützen die Veröffentlichungen Dritter. Nun, der ESET ist seit Jahren auf allen portablen Geräten und meinen Privaten installiert und arbeitet wirklich tadellos. Kaum CPU-Last und sehr erkennungssicher. Ein Beispiel dafür wäre z.B. die BKA-Variante vom Jahresanfang 2014, die der TM nicht gefunden hat, ein NOD32 sowie die Kaspersky-Notfalldisk jedoch zielsicher. Die Signatur samt eingepacktem File habe ich bei TM gesendet und schon nach 9 Tagen hatte ich eine Lösung, nach 11 Tagen alle anderen. Für ein Hersteller einer Virenscanner-Lösung ist dass schon beeindruckend langsam. Er ist besser als ein kostenloser AVIRA, aber definitiv schlechter als ein Windows 8-Embedded Defender.
Juppeck
Die Produkte von TrendMicro unterscheiden sich untereinander in den Versionen und der Zusammensetzung. Der Officescan war eine Version 10.6 in einer Enterprise Umgebung. Der Fehler tritt mit Version 11 nicht mehr auf - das RDP läuft wie gewohnt ohne Verzögerungen.
Nun, dafür funktioniert nun das Dashboard des Servers bzw. des Web-Portals nicht mehr. Die Jungs von TM haben doch glatt einfach den PHP samt Apache-Supportfiles fehlen lassen. Nun, ich habe ein Ticket aufgemacht und nun geht der Ärger erst richtig los. Eigentlich will ich nichts mehr daran machen - das Dashboard wäre zwar schön, aber schränkt mich erstmal nicht weiter ein. In 4 Monaten muss ich sowieso ein Upgrade Scenario des TM-OfficeScan machen denn Ende des ersten Quartal läuft der 3 Jahresvertrag. Ob ich die Zeit noch investieren will um das Dashboard mit Hilfe des Supports (der sehr träge ist) zu fixen, hab ich noch nicht entschieden. Es ist jedoch ein gutes Beispiel dafür, wie US-Konzerne im Ausland agieren. Die US-Fassung ist 4-6 Monate früher verfügbar als eine Deutsche Fassung und diese ist dann nicht mal fehlerfrei. Diesen PHP-Install Fehler schleppen die TM Leute schon seit wenigstens 2 Jahren mit sich rum und bekommen es nicht in den Griff. Nun, TrendMicro war mal recht gut, dass ist jedoch schon lange her. Meine eigenen Erfahrungen stützen die Veröffentlichungen Dritter. Nun, der ESET ist seit Jahren auf allen portablen Geräten und meinen Privaten installiert und arbeitet wirklich tadellos. Kaum CPU-Last und sehr erkennungssicher. Ein Beispiel dafür wäre z.B. die BKA-Variante vom Jahresanfang 2014, die der TM nicht gefunden hat, ein NOD32 sowie die Kaspersky-Notfalldisk jedoch zielsicher. Die Signatur samt eingepacktem File habe ich bei TM gesendet und schon nach 9 Tagen hatte ich eine Lösung, nach 11 Tagen alle anderen. Für ein Hersteller einer Virenscanner-Lösung ist dass schon beeindruckend langsam. Er ist besser als ein kostenloser AVIRA, aber definitiv schlechter als ein Windows 8-Embedded Defender.
Juppeck
Auch wenn der Thread hier schon einen Monat alt ist, ich habe mich hier extra angemeldet um dir zu sagen, das du mit dem Problem nicht alleine da stehst.
Ein Bekannter von mir und ich selbst haben genau das selbe Problem.
Haben auf unsere Hauptrechner Windows 8.1 und greifen auf einen PC im Netzwerk per Remote Desktop zu.
Und es läuft ziemlich schwammig und sind täglich am rumprobieren was man da noch machen kann.
Beide unserer Zugriffs PCs haben als Haupt HDD eine SSD, dies wollte ich nur erwähnen, da einige meinen das die HDD das wegen der zwischenspeicherung nicht schaffen würde...
Beim bewegen eines Fensters auf den zugriffspc ruckelt es wie die hölle.
Alle PCs hängen in einem Gigabit Netzwerk und wir beide denken uns manchmal das es doch ned sein kann das sowas in der heutigen Zeit sooo ###e trotz der schnellen internen Bandbreite ruckelt bzw. verzögert ankommt.
Habe bereits Teamviewer, RealVNC und Remote Desktop probiert alles läuft gleich.
Oder gibt es einfach noch kein ordentliches Programm aufn Markt, mit dem man mit den PC auf den man zugreift so arbeiten kann wie als wenn man direkt an ihn sitzt?
Würde mich über eine Antwort sehr freuen.
Ein Bekannter von mir und ich selbst haben genau das selbe Problem.
Haben auf unsere Hauptrechner Windows 8.1 und greifen auf einen PC im Netzwerk per Remote Desktop zu.
Und es läuft ziemlich schwammig und sind täglich am rumprobieren was man da noch machen kann.
Beide unserer Zugriffs PCs haben als Haupt HDD eine SSD, dies wollte ich nur erwähnen, da einige meinen das die HDD das wegen der zwischenspeicherung nicht schaffen würde...
Beim bewegen eines Fensters auf den zugriffspc ruckelt es wie die hölle.
Alle PCs hängen in einem Gigabit Netzwerk und wir beide denken uns manchmal das es doch ned sein kann das sowas in der heutigen Zeit sooo ###e trotz der schnellen internen Bandbreite ruckelt bzw. verzögert ankommt.
Habe bereits Teamviewer, RealVNC und Remote Desktop probiert alles läuft gleich.
Oder gibt es einfach noch kein ordentliches Programm aufn Markt, mit dem man mit den PC auf den man zugreift so arbeiten kann wie als wenn man direkt an ihn sitzt?
Würde mich über eine Antwort sehr freuen.
@Fennen:
Hallo.
Anscheinend hast Du den Thread nicht vollständig durchgelesen. Der Thread-Owner hatte speziell bei der Verwendung des RDP-Clients von Windows 8.1 Pro aus Probleme, diese konnten aber gelöst werden, in seinem Fall lag's am Virenscanner, der ein Update benötigte. Beim Thread-Owner lief der RDP-Client danach wieder einwandfrei.
Auch ansonsten, von anderen Plattformen aus und zu anderen Plattformen hin, läuft RDP im LAN eigentlich spitze. RDP ist eigentlich das "ordentliche" Programm, nach dem Du fragst.
Vielleicht trifft einer dieser Punkte bei Dir zu (ich hatte das dem TO mal gegoogelt):
"Hab' jetzt auf die schnelle ein paar Möglichkeiten gefunden (Google), woran das unter Windows 8.1 vielleicht liegen könnte:
- der oder die Switche können nicht richtig mit Windows 8.1 (dritter Treffer bei Google, kommt mir aber merkwürdig bzw. ausgeschlossen vor)
- auf ganz wenigen Webseiten wird beschrieben, daß RDP unter W8.1 dann langsam ist, wenn das Update 1 (aus April) nicht installiert ist, das OS sollte also auf Stand 8.1.1. sein , danach sind die Probleme verschwunden
- manchen hat ein neuer Grafiktreiber für den Host geholfen (kommt mir auch merkwürdig vor, RDP interessiert das Grafiksystem am Host eigentlich überhaupt nicht, es sei denn, es wird RemoteFX eingesetzt)
- manchen half es, Remote FX zu deaktivieren
- anderen hat es wiederum geholfen, die Grafiktreiber am zugreifenden Client zu aktualisieren
- bei manchen war ein TrendMicro Virenscanner ("OfficeScan") der Schuldige, TrendMicro hat danach einen Patch herausgebracht
- hier und da war trotz Update auf 8.1.1 immer noch schlechte RDP-Performance, die hatten aber keine Folgepatches zu 8.1.1 installiert, danach ging's besser
- manchen haben diese beiden Updates gefehlt: http://support.microsoft.com/kb/2883200 und http://support.microsoft.com/kb/2884846;
Du schreibst aber, daß KEIN Tool so richtig gut funktioniert, wobei Du hier RDP mit Fernwartungstools in einen Topf wirfst (RDP ist deutlich mehr als ein Fernwartungstool, eigentlich ist das ein Terminalserverzugriffsclient, mit dem täglich millionenfach flüssig gearbeitet wird).
Wenn alle diese Möglichkeiten bei Dir nicht richtig hinhauen, stimmt irgendetwas anderes nicht.
Ich habe an 2 Arbeitsstellen als Systemadmin keine Probleme mit RDP von W8.1 aus, an einer Stelle ist das sogar nur ein 100 Mbit/s-Netzwerk.
Vielleicht gehst Du mal die obige Liste durch, eventuell ist da was dabei, was bei Dir zutrifft und den RDP-Client stört.
Hinsichtlich der anderen Tools bist Du aber auch noch lange nicht am Ende.
Du hast RealVNC und Teamviewer aufgezählt. Da gibt es aber noch viele andere:
- Netviewer
- Fastviewer
- Citrix2Go
- TightVNC
- Proxy Pro
Aber, wie gesagt, RDP sollte in einem LAN schon ab 10 Mbit/s einwandfrei funktionieren, 10 Mbit/s ist für die Bandbreite, die RDP braucht, um optimal arbeiten zu können, schon das Maximum, mehr lässt sich in den Optionen des RDP-Client gar nicht auswählen, bei 10 Mbit/s muß es perfekt sein (wie ich schon sagte, mein RDP-Client läuft überall perfekt, sogar auf WAN-Strecken mit nur 2 Mbit/s symmetrisch).
Geh' mal die Liste durch oder versuch' noch mal andere Tools außer RDP. Oder, vielleicht liegt's bei Dir auch am Virenscanner?
Grüße
von
departure69
Hallo.
Anscheinend hast Du den Thread nicht vollständig durchgelesen. Der Thread-Owner hatte speziell bei der Verwendung des RDP-Clients von Windows 8.1 Pro aus Probleme, diese konnten aber gelöst werden, in seinem Fall lag's am Virenscanner, der ein Update benötigte. Beim Thread-Owner lief der RDP-Client danach wieder einwandfrei.
Auch ansonsten, von anderen Plattformen aus und zu anderen Plattformen hin, läuft RDP im LAN eigentlich spitze. RDP ist eigentlich das "ordentliche" Programm, nach dem Du fragst.
Vielleicht trifft einer dieser Punkte bei Dir zu (ich hatte das dem TO mal gegoogelt):
"Hab' jetzt auf die schnelle ein paar Möglichkeiten gefunden (Google), woran das unter Windows 8.1 vielleicht liegen könnte:
- der oder die Switche können nicht richtig mit Windows 8.1 (dritter Treffer bei Google, kommt mir aber merkwürdig bzw. ausgeschlossen vor)
- auf ganz wenigen Webseiten wird beschrieben, daß RDP unter W8.1 dann langsam ist, wenn das Update 1 (aus April) nicht installiert ist, das OS sollte also auf Stand 8.1.1. sein , danach sind die Probleme verschwunden
- manchen hat ein neuer Grafiktreiber für den Host geholfen (kommt mir auch merkwürdig vor, RDP interessiert das Grafiksystem am Host eigentlich überhaupt nicht, es sei denn, es wird RemoteFX eingesetzt)
- manchen half es, Remote FX zu deaktivieren
- anderen hat es wiederum geholfen, die Grafiktreiber am zugreifenden Client zu aktualisieren
- bei manchen war ein TrendMicro Virenscanner ("OfficeScan") der Schuldige, TrendMicro hat danach einen Patch herausgebracht
- hier und da war trotz Update auf 8.1.1 immer noch schlechte RDP-Performance, die hatten aber keine Folgepatches zu 8.1.1 installiert, danach ging's besser
- manchen haben diese beiden Updates gefehlt: http://support.microsoft.com/kb/2883200 und http://support.microsoft.com/kb/2884846;
Du schreibst aber, daß KEIN Tool so richtig gut funktioniert, wobei Du hier RDP mit Fernwartungstools in einen Topf wirfst (RDP ist deutlich mehr als ein Fernwartungstool, eigentlich ist das ein Terminalserverzugriffsclient, mit dem täglich millionenfach flüssig gearbeitet wird).
Wenn alle diese Möglichkeiten bei Dir nicht richtig hinhauen, stimmt irgendetwas anderes nicht.
Ich habe an 2 Arbeitsstellen als Systemadmin keine Probleme mit RDP von W8.1 aus, an einer Stelle ist das sogar nur ein 100 Mbit/s-Netzwerk.
Vielleicht gehst Du mal die obige Liste durch, eventuell ist da was dabei, was bei Dir zutrifft und den RDP-Client stört.
Hinsichtlich der anderen Tools bist Du aber auch noch lange nicht am Ende.
Du hast RealVNC und Teamviewer aufgezählt. Da gibt es aber noch viele andere:
- Netviewer
- Fastviewer
- Citrix2Go
- TightVNC
- Proxy Pro
Aber, wie gesagt, RDP sollte in einem LAN schon ab 10 Mbit/s einwandfrei funktionieren, 10 Mbit/s ist für die Bandbreite, die RDP braucht, um optimal arbeiten zu können, schon das Maximum, mehr lässt sich in den Optionen des RDP-Client gar nicht auswählen, bei 10 Mbit/s muß es perfekt sein (wie ich schon sagte, mein RDP-Client läuft überall perfekt, sogar auf WAN-Strecken mit nur 2 Mbit/s symmetrisch).
Geh' mal die Liste durch oder versuch' noch mal andere Tools außer RDP. Oder, vielleicht liegt's bei Dir auch am Virenscanner?
Grüße
von
departure69
