none
RemoteFX Bildartefakte RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo Zusammen,

    ich hoffe Ihr könnt mir helfen. 

    Wir haben in mehreren Netzwerkumgebungen (vollkommen unabhängig von einander) das Problem das Bildfragmente innerhalb der RDP Sitzung "hängen" bleiben und andere Fenster überlagern. 

    Zur Umgebung
     - Server: Remotedesktopserver (2012R2) - komplett durchgepatched.
     - Clients: Windows 10, Igel ThinClients, Windows 8.1 - komplett durchgepatched - mit aktuellem RDP Client (8.1)

    Das Problem tritt vorallem auf wenn Fenster minimiert oder geschlossen werden, hierbei bleiben dann teile der minimierten od. geschlossenen Fenster im Vordergrund und überlagern andere Fenster. (am häufigsten bei Outlook 2013)
    Wir konnten dieses Verhalten nur beobachten wenn die Verbindung zum Terminalserver über eine VPN Verbindung aufgebaut wird (mindestens 2,5 mbit/s down + up).

    Wir haben auf dem Remotedesktopserver per Gruppenrichtlinie folgende Einstellungen zur Performance Optimierung vorgenommen:

    - Maximale Farbtiefe auf 32 bit
    - Komprimierung für RemoteFx-Daten optmiert für geringere Netzwerkbandbreitennutzung
    - Bildqualität für adaptive RemoteFX-Grafik auf "Mittel"
    - adaptive RemoteFX-Grafiken für die Verwendung minimaler Netzwerkbandbreite optimiert

    Folgende Einstellungen haben wir schon getestet:

    - alle GPOs bezüglich RDP / RemoteFX testweise deaktiviert
    - Bildqualität für adaptive RemoteFX-Grafiken auf "lossless"
    - Bitmap Cache deaktiviert
    - Komprimierung für RemoteFX deaktiviert / aktiviert 
    - Clients komplett neu installiert / konfiguriert
    - Office Hardwarebeschleunigung deaktiviert
    - Farbtiefe alle Einstellungen getestet
    - auf den Igel ThinClients haben wir zusätzlich noch die verschiedenen Versionen von RDP (6 -> 8.1 sowie verschiedene Komprimierungsalgorithmen testen können)

    Hat einer von euch eine Idee? 

    Hier ein Screenshot:

    http://prnt.sc/bvpji0

    Direkt einfügen ging leider nicht :( 

    Vielen Dank vorab!

    Grüße

    Fkappen  

    Donnerstag, 21. Juli 2016 14:25
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden

    Moin,

    ich habe mir Deinen Post heute schon drei- oder viermal durchgelesen. Wenn ich nur einen Versuch hätte, würde ich bei diesem Fehlerbild darauf tippen, dass Dein VPN-Konzentrator (oder VPN-Client, oder beide) mehr macht als nur Traffic einpacken und tunneln. Irgendein super-smartes caching, Bandbreiten-Optimierung, irgendwas in die Richtung versucht es. Mit Bandbreite und Latenz allein kann das, was Du schilderst, nicht zu tun haben.

    Versuch doch mal, mit einem WAN Emulator (z.B. http://wanem.sourceforge.net/ ) den Einfluss von WAN ohne das VPN zu untersuchen. Treten die Artefakte über den WAN-Emulator nicht auf, hast Du den Nachweis, dass es am VPN liegt. Treten sie doch auf, dann liegt es wohl tatsächlich an Bandbreite und Latenz, und man muss schauen, wie man das noch abstellen kann. Vielleicht kann man ja für RDP auf das VPN verzichten und stattdessen mit einem RD Gateway arbeiten...

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Donnerstag, 21. Juli 2016 20:20
    |

Alle Antworten

  • Question
    Anmelden
    1
    Anmelden

    Moin,

    ich habe mir Deinen Post heute schon drei- oder viermal durchgelesen. Wenn ich nur einen Versuch hätte, würde ich bei diesem Fehlerbild darauf tippen, dass Dein VPN-Konzentrator (oder VPN-Client, oder beide) mehr macht als nur Traffic einpacken und tunneln. Irgendein super-smartes caching, Bandbreiten-Optimierung, irgendwas in die Richtung versucht es. Mit Bandbreite und Latenz allein kann das, was Du schilderst, nicht zu tun haben.

    Versuch doch mal, mit einem WAN Emulator (z.B. http://wanem.sourceforge.net/ ) den Einfluss von WAN ohne das VPN zu untersuchen. Treten die Artefakte über den WAN-Emulator nicht auf, hast Du den Nachweis, dass es am VPN liegt. Treten sie doch auf, dann liegt es wohl tatsächlich an Bandbreite und Latenz, und man muss schauen, wie man das noch abstellen kann. Vielleicht kann man ja für RDP auf das VPN verzichten und stattdessen mit einem RD Gateway arbeiten...

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Donnerstag, 21. Juli 2016 20:20
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    vielen Dank für die schnelle Antwort. Ich werde das mal mit einem WAN Emulator versuchen nachzustellen und gebe dann nochmal ein Feedback. 

    Folgendes ist mir noch im Eventlog aufgefallen:

    Die Mehrfachtransportverbindung wurde für den Tunnel "3" getrennt, der Transporttyp wurde auf "TCP: Reason Code: 1 (No Client UDP Support)" festgelegt.

    Könnte das die Ursache sein? 

    Grüße


    Freitag, 22. Juli 2016 10:41
    |
  • Question
    Anmelden
    1
    Anmelden

    Unwahrscheinlich, er hat ja richtigerweise erkannt, dass der Client UDP nicht verwenden möchte.

    Du kannst UDP aber auch auf dem Server per GPO deaktivieren und schauen, ob  es schon hilft...

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Freitag, 22. Juli 2016 10:55
    |
  • Question
    Anmelden
    0
    Anmelden
    Ich meine generell wegen der fehlenden Fähigkeit UDP zu verwenden? 
    Freitag, 22. Juli 2016 10:59
    |
  • Question
    Anmelden
    1
    Anmelden
    Wenn UDP in Deinem VPN zwar theoretisch möglich, aber unzuverlässig wäre, könnte das dieses Verhalten hervorrufen. Versuch's mal ganz abzuschalten, und zwar am Server.

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Freitag, 22. Juli 2016 11:16
    |
  • Question
    Anmelden
    1
    Anmelden
    > Wenn UDP in Deinem VPN zwar theoretisch möglich, aber unzuverlässig
     
    UDP verursacht meistens Probleme über VPN-Hardware - die Pakete werden
    gern mal out of order ausgeliefert, und manche Anwendungen kommen damit
    nicht klar :-)
     
    Freitag, 22. Juli 2016 12:08
    |
  • Question
    Anmelden
    0
    Anmelden

    Ich hatte ein Problem mit Artefakten unter RemoteFX und Windows 8.1 (keine Überlagerungen, aber Bildstörungen).

    So habe ich es gelöst: Auf dem Host den Gerätemanager aufrufen, die VGPU auswählen und dann durch die Menüs durch hangeln:

    "Treiber aktualisieren"->"Auf dem Computer nach Treibersoftware suchen"->"Aus einer Liste von Gerätetreibern auf dem Computer auswählen".

    Man sieht dann eine Liste mit zwei RemoteFX GPUs. Man wählt die erste aus und nach der Installation sollten die Artefakte verschwunden sein (war zumindest bei mir so). Es gibt aber ein Paar Nebenwirkungen: Die "Metro"-Oberfläche funktioniert nicht mehr richtig (Apps starten und minimieren sich sofort wieder, die Suche im Homescreen ist ebenfalls außer Gefecht). Außerdem stürzt der Desktop Internet Explorer ab. Alles andere läuft aber einwandfrei. Wenn man also Classic Shell verwendet, und einen anderen Browser als den IE, kann man diese Lösungsmöglichkeit mal probieren.

    Es sieht so aus, als ob die ganzen "Metro"-Ergänzungen dem RemoteFX-Treiber nicht gut getan haben.

    • Bearbeitet ajac123 Mittwoch, 11. Juli 2018 12:31
    Mittwoch, 11. Juli 2018 12:29
    |
  • Question
    Anmelden
    0
    Anmelden

    Man kann aber auch den RemoteFX einfach mal abschalten. Leider sind die Anwendungen heute inzwischen so grafiklastig, dass es selbst bei hoher Bandbreite zu Problemen in der Darstellung kommt.
    Bei unserem Wechsel von Office2010 zu Office2016 war selbst das Verschieben von Fenstern schon eine langwierige Aktion.
    Trotz Uploads von 20MBit auf beiden Seiten fahre ich im Moment am Besten via VPN und RDP mit 16-Bit Farbtiefe, 2MBit-Lan und ausschließlich Desktopgestaltung und Visuelle Stile angehakt.
    RemoteFX ist nicht mehr im EInsatz.

    Man erhält zwar nicht mehr die volle Grafikdarstellung, aber ich will ja Arbeiten, was nun wieder flott geht, und nicht nur Bilder gucken.

    Donnerstag, 12. Juli 2018 09:04
    |