Kurze Information für die Administratoren unter der Leserschaft, die mit RDP Shortpath auf virtueller Azure-Desktops zugreifen müssen. Microsoft hat zum 4. Februar 2026 die allgemeine Verfügbarkeit von RDP Shortpath configuration für Windows bekannt gegeben. Hier einige Informationen dazu.
Was ist RDP Shortpath?
RDP Shortpath ist gemäß diesem Artikel eine Funktion, die für den Zugriff auf virtuelle Azure-Desktop per RDP entwickelt wurde. Die Funktion nutzt zwar das Remote Desktop Protocol, verbessert aber die RDP-Verbindung durch die Einrichtung eines UDP-basierter Transport zwischen dem Clientgerät und dem Sitzungshost.
Im Gegensatz zum herkömmlichen TCP-basierten Reverse-Connect-Transport, der als Fallback dient, bietet der UDP-basierte Transport eine bessere Verbindungszuverlässigkeit und geringere Latenz.
RDP Shortpath verwendet ICE (Interactive Connectivity Establishment) als Mechanismus zum Aufbau direkter oder weitergeleiteter UDP-Verbindungen zwischen dem RDP-Client und dem Sitzungshost. ICE ermöglicht die Ermittlung und Auswahl des besten Verbindungspfads, indem es mögliche Netzwerkkandidaten sammelt und Konnektivitätstests durchführt. Dies gewährleistet einen zuverlässigen Kommunikationskanal mit geringer Latenz, was ein vorrangiges Ziel von RDP Shortpath ist.
RDP Shortpath Configuration per GPO/Intune verfügbar
Ich bin über nachfolgenden Tweet auf die Veröffentlichung aufmerksam geworden, die zum 4. Februar 2026 im Techcommunity-Artikel Announcing General Availability of RDP Shortpath Configuration via GPO and Microsoft Intune angekündigt wurde.
Die Entwickler geben bekannt, dass nun die zentralisierten RDP-Shortpath-Konfiguration mit Microsoft Intune und Gruppenrichtlinien (GPO) allgemein möglich sei. Mit dem Update haben IT-Administratoren eine einheitliche, richtliniengesteuerte Möglichkeit, zu steuern, welche RDP-Shortpath-Modi (verwaltet, öffentlich/STUN, öffentlich/TURN) auf Azure Virtual Desktop (AVD)-Sitzungshosts und Windows 365 Cloud-PCs aktiviert sind. Mit dieser Version können Administratoren:
Diese Shortpath-Steuerelemente werden nun direkt auf registrierungsgestützte Richtlinien abgebildet, sodass IT-Administratoren auf einfache Weise ein einheitliches Verhalten in großen oder verteilten Umgebungen aufrechterhalten können, schreibt Microsoft.
RDP Shortpath bietet mehrere optimierte UDP-basierte Transportpfade – Managed, Public/STUN und Public/TURN –, die die Verbindungsleistung und -zuverlässigkeit in verschiedenen Netzwerkumgebungen verbessern. Diese Optionen bilden zusammen den Funktionsumfang von RDP Shortpath. Microsoft empfiehlt, alle Optionen aktiviert zu lassen, damit automatisch der beste Pfad ausgewählt werden kann.
Benötigt ein Unternehmen jedoch strengere Kontrollen (z.B. Deaktivierung der STUN-basierten Traversal, um sicherzustellen, dass der Datenverkehr nur über den dedizierten Port und das Subnetz von TURN fließt), können Administratoren dies durch eine zentralisierte Konfiguration erreichen.
MVP: 2013 – 2016
"Im Gegensatz zum herkömmlichen TCP-basierten Reverse-Connect-Transport, der als Fallback dient, bietet der UDP-basierte Transport eine bessere Verbindungszuverlässigkeit und geringere Latenz."
Ganz stumpf mal: Häää?
RDP hat seit Ewigkeiten UDP als Standardprotokoll. Man kann es auf TCP umstellen, macht man auch bei fehleranfälligen Verbindungen. Und es steht ja auch im Text, TCP dient als Fallback.
Und wie kommt man denn zu der Aussage, dass UDP eine bessere Verbindungszuverässigkeit liefert? UDP hat keine Flusskontrolle, Pakete können verloren gehen und das muss dann ggf. auf der Protokollebene darüber gehandelt werden, aber UDP an sich ist praktisch das Gegenteil von Verbindungszuverlässigkeit.
Einzig korrekt scheint mir hier, dass der Vorteil der fehlenden Flusskontrolle tatsächlich eine geringere Latenz ist.
Oder verstehe ich hier gerade etwas komplett falsch?
Meine Lesart ist, dass ICE (Interactive Connectivity Establishment) die Ermittlung und Auswahl des besten Verbindungspfads durch Konnektivitätstests ermöglicht, und so die Verbindungszuverlässigkeit verbessert – mag mich aber täuschen.
Es ist für mich wirklich verwirrend. Der normale RDP Client hat sowas bereits, jedenfalls formal. Bei Schwankungen der Verbindungsqualität passt er sich dynamisch an.
Das funktioniert allerdings, so wie bei Microsoft viele der Automatismen, eher suboptimal.
Ist das hier daher vielleicht nur eine neue Iteration dessen, was wir schon hatten, nur mit neuen Versprechen?