21
Grafikkarte, onboard, dediziert, RDP
Guten Morgen in die Runde!
Heute mal kurz und knapp.
Frage: Wie kann ich feststellen ob und ggfs. welche Aufgaben von der intern oder/und der dedizierten Grafikkarte übernommen werden?
HW: Tower i7 (7700), 32 GB RAM, SSD, GTX 1060, MSI-Board H110 M Pro-D
SW: Allplan und Zugriff über RDP
Der Rechner wurde damals eher als "Testsystem" angeschafft. Die Grafikkarte (Mid-Class Spielekarte) ist NICHT zertifiziert für die SW Allplan und mW. sind sowohl die interne, als auch die dedizierte Karte nicht FX-fähig.
Wenn ich an der Maschine sitze, ist der Monitor (natürlich) an der dedizierten Karte angeschlossen und ich arbeite über die Nvidia-Konfigurationen. Das klappt auch und die 3D-Anforderungen des Users sind (faktisch) nicht existent, weil eigentlich reine 2D-Tätigkeit.
Jetzt greife ich über RDP auf den gleichen Arbeitsplatz zu. Läuft das dann automatisch über die bordeigene i7 Grafik oder die GTX?
Hintergrund der Frage: Wie wichtig wäre bei einem HW-Upgrade die dedizierte Grafikkarte, wenn die Nutzung überwiegend über RDP erfolgt ... gerade im Hinblick auf die immer leistungsfähigere Onboard-Grafik der (AMD) Endgeräte. Wenn die bei RDP faktisch gar nicht angesprochen wird, können wir uns das Towergehäuse sparen
Zudem kämpfe ich gerade mit einem “The graphic display components in the remote session failed to start up 0x11” und versuche den “richtigen” bzw. defekten Treiber dafür zu finden
Heute mal kurz und knapp.
Frage: Wie kann ich feststellen ob und ggfs. welche Aufgaben von der intern oder/und der dedizierten Grafikkarte übernommen werden?
HW: Tower i7 (7700), 32 GB RAM, SSD, GTX 1060, MSI-Board H110 M Pro-D
SW: Allplan und Zugriff über RDP
Der Rechner wurde damals eher als "Testsystem" angeschafft. Die Grafikkarte (Mid-Class Spielekarte) ist NICHT zertifiziert für die SW Allplan und mW. sind sowohl die interne, als auch die dedizierte Karte nicht FX-fähig.
Wenn ich an der Maschine sitze, ist der Monitor (natürlich) an der dedizierten Karte angeschlossen und ich arbeite über die Nvidia-Konfigurationen. Das klappt auch und die 3D-Anforderungen des Users sind (faktisch) nicht existent, weil eigentlich reine 2D-Tätigkeit.
Jetzt greife ich über RDP auf den gleichen Arbeitsplatz zu. Läuft das dann automatisch über die bordeigene i7 Grafik oder die GTX?
Hintergrund der Frage: Wie wichtig wäre bei einem HW-Upgrade die dedizierte Grafikkarte, wenn die Nutzung überwiegend über RDP erfolgt ... gerade im Hinblick auf die immer leistungsfähigere Onboard-Grafik der (AMD) Endgeräte. Wenn die bei RDP faktisch gar nicht angesprochen wird, können wir uns das Towergehäuse sparen
Zudem kämpfe ich gerade mit einem “The graphic display components in the remote session failed to start up 0x11” und versuche den “richtigen” bzw. defekten Treiber dafür zu finden
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: 647077
Url: https://administrator.de/forum/grafikkarte-onboard-dediziert-rdp-647077.html
Ausgedruckt am: 22.12.2024 um 20:12 Uhr
21 Kommentare
Neuester Kommentar
DIe 3D Beschleunigung der Grafikkarte wirst du bei RDP nur geniessen können, wenn du RDP im Konsolenmodus verbindest, dann hast du die Auflösung der Konsole, wie sie auch auf dem angeschlossenen Monitor existiert. Wenn du RDP ohne Konsolenmodus startest, hast du eine emulierte Softwaregrafikkarte ohne 3D Beschleunigung, zu erkennen daran, dass du die Monitorauflösung des Clients benutzt / also sich der RDP Client mit seiner Auflösung an den Clientmonitor angepasst hat.
Weiterhin hast du im Konsolenmodus die Möglichkeit im Taskmanager zu erkennen, welcher Task auf welche GPU zugreift. Über die Nvidia Treiber Software kann man voreinstellen welche GPU von welchem Programm verwendet werden soll.
Weiterhin hast du im Konsolenmodus die Möglichkeit im Taskmanager zu erkennen, welcher Task auf welche GPU zugreift. Über die Nvidia Treiber Software kann man voreinstellen welche GPU von welchem Programm verwendet werden soll.
Hallo,
weder noch - das erfolgt in dem Fall über einen imaginären Adapter, der die Grafikdaten in die RDP-Session schießt. IMO heißt der "Microsoft Display Adapter".
Normalerweise erfolgt 3D über RDP über "echte" RDP-Hosts aka "Terminalserver". Und für die gibt es entsprechende Lösungen - bei nVidia heißt das z.B. "nVidia Grid".
Früher gab es tatsächlich mal spezielle 3D-Karten, die von der 2D-Karte via Kabelpeitsche ein Signal abgegriffen und bei Bedarf durchgeschleift haben. Das ist inzwischen obsolet.
Heutzutage gibt es zwei Szenarien:
- ein PC hat Chipsatzgrafik und eine 3D-Karte: In dem Fall erfolgt die Berechnung über die Karte, an der letztendlich der Monitor hängt.
- ein Notebook hat Chipsatzgrafik und eine 3D-Karte: In dem Fall gibt es nur einen Grafikausgang für beide Karten. In den Treibereinstellungen kannst Du aber für bestimmte Programme festlegen, welche Grafikkarte sie nutzen sollen - bei nVidia heißt das z.B. "nVidia Optimus".
Nichtsdestotrotz: Sobald Du via RDP auf der Mühle herumklöterst, switcht dein Geraffel auf den RDP-Grafikadapter um. Und das ist auch ganz gut so, da nur dieser bestimmte Funktionen abbilden kann (z.B. das dynamische Anpassen der Auflösung wenn Du das RDP-Fenster vergrößerst oder verkleinerst).
Gruß,
Jörg
weder noch - das erfolgt in dem Fall über einen imaginären Adapter, der die Grafikdaten in die RDP-Session schießt. IMO heißt der "Microsoft Display Adapter".
Normalerweise erfolgt 3D über RDP über "echte" RDP-Hosts aka "Terminalserver". Und für die gibt es entsprechende Lösungen - bei nVidia heißt das z.B. "nVidia Grid".
Früher gab es tatsächlich mal spezielle 3D-Karten, die von der 2D-Karte via Kabelpeitsche ein Signal abgegriffen und bei Bedarf durchgeschleift haben. Das ist inzwischen obsolet.
Heutzutage gibt es zwei Szenarien:
- ein PC hat Chipsatzgrafik und eine 3D-Karte: In dem Fall erfolgt die Berechnung über die Karte, an der letztendlich der Monitor hängt.
- ein Notebook hat Chipsatzgrafik und eine 3D-Karte: In dem Fall gibt es nur einen Grafikausgang für beide Karten. In den Treibereinstellungen kannst Du aber für bestimmte Programme festlegen, welche Grafikkarte sie nutzen sollen - bei nVidia heißt das z.B. "nVidia Optimus".
Nichtsdestotrotz: Sobald Du via RDP auf der Mühle herumklöterst, switcht dein Geraffel auf den RDP-Grafikadapter um. Und das ist auch ganz gut so, da nur dieser bestimmte Funktionen abbilden kann (z.B. das dynamische Anpassen der Auflösung wenn Du das RDP-Fenster vergrößerst oder verkleinerst).
Gruß,
Jörg
Hallo,
Welches Windows läuft denn da drauf? Ohne solche grundlegenden Informationen kann man kaum helfen.
@117471 hat teilweise recht. Für RDP wird i.d.R. eine virtuelle Grafikkarte eingesetzt. Die hat erst einmal nichts mit der integrierten oder dedizierten Grafikkarte zu tun.
Um die Leistung der Grafikkarte über RDP zu nutzen braucht man RemoteFX. Das ist jedoch ein spezielles Feature z.B. von Windows Server 2016. Dazu braucht man noch Hyper-V. (Ob das dann wiederum für Remote FX 3D zwingend eine Quattro braucht, weiß ich nicht.) Gesteuert wird das über bestimmte Gruppenrichtlinien. (Mit einer einfachen Professional kommst Du da mit RDP und RemoteFX nicht weiter.)
gpedit.msc auf dem RDP Host
-> Administrative Vorlagen
-> Windows Komponenten
-> Remotedesktopdienste
-> Remotedesktopsitzungs-Host
-> Umgebung für Remotesitzung
-> Hardwaregrafikadapter für alle Remotesitzungen verwenden aktivieren
Alternative, die schnell einzurichten ist und auch funktioniert.
https://parsec.app
Allerdings ist es eine Fernsteuerung. Dafür extrem schnell und Du kannst die Grafikbeschleunigung nutzen. Im Gegensatz zu RDP wird der Bildschirm nicht gesperrt. Für Full-HD und 60fps braucht man da aber schon schnell 25Mbit Upload am Host.
Die Lösung für Firmen ist übrigens "parsec for Teams".
https://parsec.app/teams
Gruß
its
Welches Windows läuft denn da drauf? Ohne solche grundlegenden Informationen kann man kaum helfen.
@117471 hat teilweise recht. Für RDP wird i.d.R. eine virtuelle Grafikkarte eingesetzt. Die hat erst einmal nichts mit der integrierten oder dedizierten Grafikkarte zu tun.
Um die Leistung der Grafikkarte über RDP zu nutzen braucht man RemoteFX. Das ist jedoch ein spezielles Feature z.B. von Windows Server 2016. Dazu braucht man noch Hyper-V. (Ob das dann wiederum für Remote FX 3D zwingend eine Quattro braucht, weiß ich nicht.) Gesteuert wird das über bestimmte Gruppenrichtlinien. (Mit einer einfachen Professional kommst Du da mit RDP und RemoteFX nicht weiter.)
gpedit.msc auf dem RDP Host
-> Administrative Vorlagen
-> Windows Komponenten
-> Remotedesktopdienste
-> Remotedesktopsitzungs-Host
-> Umgebung für Remotesitzung
-> Hardwaregrafikadapter für alle Remotesitzungen verwenden aktivieren
Alternative, die schnell einzurichten ist und auch funktioniert.
https://parsec.app
Allerdings ist es eine Fernsteuerung. Dafür extrem schnell und Du kannst die Grafikbeschleunigung nutzen. Im Gegensatz zu RDP wird der Bildschirm nicht gesperrt. Für Full-HD und 60fps braucht man da aber schon schnell 25Mbit Upload am Host.
Die Lösung für Firmen ist übrigens "parsec for Teams".
https://parsec.app/teams
Gruß
its
Hallo,
Warum denn nur "teilweise"? Ich meine, so rein interessehalber.
/me lernt ja gerne dazu
Gruß,
Jörg
Warum denn nur "teilweise"? Ich meine, so rein interessehalber.
/me lernt ja gerne dazu
Gruß,
Jörg
Zitat von @117471:
/me lernt ja gerne dazu
/me lernt ja gerne dazu
Ich ja auch ständig. Übrigens, im LAN ist freeRDP auf 'nem Raspberry Pi OS (mit aktivierter Grafikbeschleunigung) detlich schneller als der Standard-RDP-Client einer Windows-Kiste.
xfreerdp /f /sec:nla /microphone:sys:alsa /sound:sys:alsa /clipboard /u:Benutzer /p:Kennwort /rfx /gfx /gfx-h264 /multitransport /network:auto -bitmap-cache -glyph-cache /gdi:hw -fonts /usb:auto /v:IPAdresseRDPServer
Allerdings geht dann auch die Datenrate auf dem NIC des Windows-Host beim Filmegucken "durch die Decke".
(Ist vielleicht etwas für eines Deiner Raspi-Projekte.
)Gruß
its
Hallo,
und warum hatte ich "nur teilweise" Recht? Wo lag ich denn falsch?
Gruß,
Jörg
und warum hatte ich "nur teilweise" Recht? Wo lag ich denn falsch?
Gruß,
Jörg
Zitat von @117471:
Hallo,
und warum hatte ich "nur teilweise" Recht? Wo lag ich denn falsch?
Gruß,
Jörg
Hallo,
und warum hatte ich "nur teilweise" Recht? Wo lag ich denn falsch?
Gruß,
Jörg
Nur weil Du's bist.
weder noch - das erfolgt in dem Fall über einen imaginären Adapter, der die Grafikdaten in die RDP-Session schießt. IMO heißt der "Microsoft Display Adapter".
Kann auch anders heißen. Je nach RDP-Host-Variante.Normalerweise erfolgt 3D über RDP über "echte" RDP-Hosts aka "Terminalserver". Und für die gibt es entsprechende Lösungen - bei nVidia heißt das z.B. "nVidia Grid".
Nannte sich mal unter Windows RemoteFX. Hat M$ aus Sicherheitsgründen erstmal wieder deaktiviert (KB4570006, muss man wieder manuell aktivieren). Haben die aus 2019 rausgeschmissen. Muss kein Terminalserver sein, sondern Windows Server (2008 bis 2016, allerdings in Hyper-V erst seit 2012 bis 2016 mittels SUD und DDA) reicht.Früher gab es tatsächlich mal spezielle 3D-Karten, die von der 2D-Karte via Kabelpeitsche ein Signal abgegriffen und bei Bedarf durchgeschleift haben. Das ist inzwischen obsolet.
Was ist den das für ein Voodoo-Zauber? Heutzutage gibt es zwei Szenarien:
Nicht nur. Mittlerweile hängt es auch von verwendeten Protokoll ab. (Und sieh dir mal Braille-Lösungen an.)- ein PC hat Chipsatzgrafik und eine 3D-Karte: In dem Fall erfolgt die Berechnung über die Karte, an der letztendlich der Monitor hängt.
- ein Notebook hat Chipsatzgrafik und eine 3D-Karte: In dem Fall gibt es nur einen Grafikausgang für beide Karten. In den Treibereinstellungen kannst Du aber für bestimmte Programme festlegen, welche Grafikkarte sie nutzen sollen - bei nVidia heißt das z.B. "nVidia Optimus".
Bei RDP und RemoteFX erfolgt die Berechnung (außer bei durchgeschleifter Grafikkate) über den Prozessor.- ein Notebook hat Chipsatzgrafik und eine 3D-Karte: In dem Fall gibt es nur einen Grafikausgang für beide Karten. In den Treibereinstellungen kannst Du aber für bestimmte Programme festlegen, welche Grafikkarte sie nutzen sollen - bei nVidia heißt das z.B. "nVidia Optimus".
Nichtsdestotrotz: Sobald Du via RDP auf der Mühle herumklöterst, switcht dein Geraffel auf den RDP-Grafikadapter um. Und das ist auch ganz > gut so, da nur dieser bestimmte Funktionen abbilden kann (z.B. das dynamische Anpassen der Auflösung wenn Du das RDP-Fenster vergrößerst oder verkleinerst).
Sieh Dir mal hierzu XDDM und WDDM an. Gab hier auch schon ein paar Foreneinträge (und Hilferufe).Gruß
its
Zitat von @NordicMike:
DIe 3D Beschleunigung der Grafikkarte wirst du bei RDP nur geniessen können, wenn du RDP im Konsolenmodus verbindest, dann hast du die Auflösung der Konsole, wie sie auch auf dem angeschlossenen Monitor existiert.
DIe 3D Beschleunigung der Grafikkarte wirst du bei RDP nur geniessen können, wenn du RDP im Konsolenmodus verbindest, dann hast du die Auflösung der Konsole, wie sie auch auf dem angeschlossenen Monitor existiert.
Dafür sind allerdings einige Vorarbeiten am Host vorzunehmen. Außerdem wird dann daraus eine Fernsteuerung und keine Terminal-Sitzung mehr.
Damit das klappt, müssen ein paar Registry-Einträge gesetzt werden. Problematisch daran: dadurch kann man den Bildschirm des Users (mit seinen eigenen Zugangsdaten) beobachten und je nach Registry-Wert bekommt der User auch keinen Hinweis. Daher bin ich mir nicht sicher, ob ich die Einträge hier posten darf. Ich würde da einen Verstoß gegen die Forenregeln vermuten.
Und wirklich "geniessen" kann man die Grafik bei schnellen Bildschirminhalten auch nicht. Wird schon ziemlich pixelig.
Gruß
its
Hallo,
ah - O.K.
Ich war mal auf 'ner Hausmesse bei Wortmann, da haben die über das Thema referiert. Da ging es in erster Linie um die nVidia-Gridlösung; wobei das auch schon wieder 2 oder 3 Jahre her ist
Gruß,
Jörg
ah - O.K.
Ich war mal auf 'ner Hausmesse bei Wortmann, da haben die über das Thema referiert. Da ging es in erster Linie um die nVidia-Gridlösung; wobei das auch schon wieder 2 oder 3 Jahre her ist
Gruß,
Jörg
Zitat von @Visucius:
Zudem kämpfe ich gerade mit einem “The graphic display components in the remote session failed to start up 0x11” und versuche den “richtigen” bzw. defekten Treiber dafür zu finden
Zudem kämpfe ich gerade mit einem “The graphic display components in the remote session failed to start up 0x11” und versuche den “richtigen” bzw. defekten Treiber dafür zu finden
Ich vermute mal hier eine veraltete Windows 10 Version 1903. Versuche mal das System zu aktualisieren.
Kann aber auch sein, dass Du hier eine Direct3D-Anwendung unter RDP starten möchtest. Siehe dazu die anderen Einträge.
Gruß
its
Zunächst mal vielen Dank.
Tipps gehe ich morgen in Ruhe durch und Freitag bin ich dann an der Maxchine.
PS: Win 10 Pro am Server, MacOS am Client
Parsec schaue ich mir an. Hatten schon mit vnc, parallels, usw experimentiert und vor 2 Jahren z.B. auch mal shadow.tech
Tipps gehe ich morgen in Ruhe durch und Freitag bin ich dann an der Maxchine.
PS: Win 10 Pro am Server, MacOS am Client
Parsec schaue ich mir an. Hatten schon mit vnc, parallels, usw experimentiert und vor 2 Jahren z.B. auch mal shadow.tech
Prüfe ich. Dachte Update 2004 sei das Problem ... zumindest hat es in der Vergangenheit problemlos funktioniert.
Hm, Parsec habe ich mal getestet. Performant scheint es ja zu sein, nur läuft das ja ausschließlich mit einem Parsec-Account. Das scheint mir ein ähnliches Setup wie bei Teamviewer zu sein:
Host/Server meldet sich bei Parsec und Client ebenso und die Daten laufen über einen “Parsec-Server”. Das mag zwar performant sein aber ich wüsste jetzt nicht, wie ich dieses Setup auf das lokale Netzwerk beschränken soll (Fritzbox). Und für ein dauerhaftes Setup auf nem Arbeitsrechner ist mir das zu “offen”.
Die Stabilität des RDP-Zugriffs habe ich hoffentlich wieder im Griff (teste noch). Der Rechner hatte neben der orginären Netzwerkkarte noch 2 Hyper-V-Netzwerkkarten und aus unerfindlichen Gründen war dort eine fixe IP hinterlegt ... die, die eigentlich auf die orginäre Netzwerkkarte verweisen sollte ... alles etwas spooky.
Nach dreimal umrühren hat sich das wohl alle paar Tage zerschossen. Bewundernswert, dass es überhaupt zwischenzeitlich funktionierte.
VG
Host/Server meldet sich bei Parsec und Client ebenso und die Daten laufen über einen “Parsec-Server”. Das mag zwar performant sein aber ich wüsste jetzt nicht, wie ich dieses Setup auf das lokale Netzwerk beschränken soll (Fritzbox). Und für ein dauerhaftes Setup auf nem Arbeitsrechner ist mir das zu “offen”.
Die Stabilität des RDP-Zugriffs habe ich hoffentlich wieder im Griff (teste noch). Der Rechner hatte neben der orginären Netzwerkkarte noch 2 Hyper-V-Netzwerkkarten und aus unerfindlichen Gründen war dort eine fixe IP hinterlegt ... die, die eigentlich auf die orginäre Netzwerkkarte verweisen sollte ... alles etwas spooky.
Nach dreimal umrühren hat sich das wohl alle paar Tage zerschossen. Bewundernswert, dass es überhaupt zwischenzeitlich funktionierte.
VG
Zitat von @Visucius:
Hm, Parsec habe ich mal getestet. Performant scheint es ja zu sein, nur läuft das ja ausschließlich mit einem Parsec-Account. Das scheint mir ein ähnliches Setup wie bei Teamviewer zu sein:
Host/Server meldet sich bei Parsec und Client ebenso und die Daten laufen über einen “Parsec-Server”. Das mag zwar performant sein aber ich wüsste jetzt nicht, wie ich dieses Setup auf das lokale Netzwerk beschränken soll (Fritzbox). Und für ein dauerhaftes Setup auf nem Arbeitsrechner ist mir das zu “offen”.
Die Frage ist eher, ob dur mit dem vorhandenen Setup eine Alternative mit Hardware-Beschleunigung hinkriegst.Hm, Parsec habe ich mal getestet. Performant scheint es ja zu sein, nur läuft das ja ausschließlich mit einem Parsec-Account. Das scheint mir ein ähnliches Setup wie bei Teamviewer zu sein:
Host/Server meldet sich bei Parsec und Client ebenso und die Daten laufen über einen “Parsec-Server”. Das mag zwar performant sein aber ich wüsste jetzt nicht, wie ich dieses Setup auf das lokale Netzwerk beschränken soll (Fritzbox). Und für ein dauerhaftes Setup auf nem Arbeitsrechner ist mir das zu “offen”.
Die Stabilität des RDP-Zugriffs habe ich hoffentlich wieder im Griff (teste noch). Der Rechner hatte neben der orginären Netzwerkkarte noch 2 Hyper-V-Netzwerkkarten und aus unerfindlichen Gründen war dort eine fixe IP hinterlegt ... die, die eigentlich auf die orginäre Netzwerkkarte verweisen sollte ... alles etwas spooky.
Gruß
its
Zitat von @IT-Spezi:
Die Frage ist eher, ob dur mit dem vorhandenen Setup eine Alternative mit Hardware-Beschleunigung hinkriegst.
Da hast du selbstredend Recht. Ich wäge nur den Performance-Vorteil gegen “ein offenes Scheunentor” ab. Und da ist der Leidensdruck bei der Geschwindigkeit nicht so überragend Die Frage ist eher, ob dur mit dem vorhandenen Setup eine Alternative mit Hardware-Beschleunigung hinkriegst.
... Außerdem will ich das “RDP-Consolen-Thema” erstmal testen.Zudem hab ich hier im Thread (wie von mir angefragt) auch mehr über den Hintergrund gelernt und würde wohl beim nächsten mal ganz auf die dedizierte Grafikkarte verzichten - die ist für die Situation und den Kundennutzen bisher weniger relevant als erwartet.
Wieso jetzt 2 Hyper-V Netzwerkkarten? Ich dachte, Du hast Windows Pro 2004 im Einsatz und greifst direkt darauf zu. Oder virtualisierst Du auf einem 2004 eine andere Windows-Instanz, auf die Du per RDP zugreifen möchtest? Creepy.
Ja, ich hatte da mal testweise 2 andere Hyper-V-Instanzen druff (Windows und Ubuntu) und in den Windows-10 Pro/20H2-Netzwerkeinstellungen sind dann halt noch die virtuellen Netzwerkkarten von Hyper-V aktiv. Erklärt aber nicht, warum eine von denen “meine” fixe IP hat. Die getesteten Hyper-V-Instanzen nutzten andere IP-Adressen.Zugreifen möchte ich sozusagen “plain auf Blech”.
"plan auf Blech" zuzugreifen geht auch über RDP mit der physikalisch vorhandenen Grafikkarte im Konsolenmodus. Bei Windows 10 nur 1 Benutzer gleichzeitig, bei Server zwei Benutzer, die beide Admin Rechte auf dem Server benötigen.
Das hat jedoch mit einem Hyper-V nichts zu tun.
Das hat jedoch mit einem Hyper-V nichts zu tun.
Zitat von @NordicMike:
"plan auf Blech" zuzugreifen geht auch über RDP mit der physikalisch vorhandenen Grafikkarte im Konsolenmodus. Bei Windows 10 nur 1 Benutzer gleichzeitig, bei Server zwei Benutzer, die beide Admin Rechte auf dem Server benötigen.
Das hat jedoch mit einem Hyper-V nichts zu tun.
"plan auf Blech" zuzugreifen geht auch über RDP mit der physikalisch vorhandenen Grafikkarte im Konsolenmodus. Bei Windows 10 nur 1 Benutzer gleichzeitig, bei Server zwei Benutzer, die beide Admin Rechte auf dem Server benötigen.
Das hat jedoch mit einem Hyper-V nichts zu tun.
Alles richtig! Geht bitte wieder weg vom Hyper-V ... in dem Kontext gab es nur eine “Fehlkonfiguration”, die mein bisheriges RDP-Setup alle paar Tage zerschossen hat und ich habe es jetzt hoffentlich dauerhaft behoben. Das war die eine Baustelle!
Die zweite: Grafikkarte und RDP ...
da habe ich auf Deinen Tipp am Anfang hier schon etwas nachgelesen und werde das mit der Console noch ausprobieren. Frage mich allerdings noch, ob ich das überhaupt von nem Mac-Client zu Windows 10Pro/Host hinbekomme. Die User-Limitierungen sind mir (leider) alle bekannt ... die früheren “Hacks” sind erfahrungsgemäß nicht von Dauer.
Also unter Linux über xfreedrp bemerkt man die Konsolen-Grafikbeschleunigung. Unter MAC kann ich es dir leider nicht sagen.
Zitat von @NordicMike:
"plan auf Blech" zuzugreifen geht auch über RDP mit der physikalisch vorhandenen Grafikkarte im Konsolenmodus. Bei Windows 10 nur 1 Benutzer gleichzeitig, bei Server zwei Benutzer, die beide Admin Rechte auf dem Server benötigen.
Der RDP-Zugriff im Konsolenmodus funktioniert nur, wenn der User schon angemeldet ist. Wenn die Kiste nur hochfährt und beim Anmeldefenster steht, dann kann man den nicht nutzen. Erst wenn der User sich lokal angemeldet hat, dann kann man mitschauen bzw. wie bei einer Fernwartungssoftware die Mauskontrolle übernehmen. (Ein Autologin wäre also hier notwendig.) Die Performance ist deutlich schlechter, als bei einer normalen RDP-Sitzung. Rechtlich ist der Modus schon deshalb problematisch, da der User gar keine Info erhält, dass sich gerade drauf geschaltet wurde. Er kann also von mißtrauischen Chefs zur Überwachung genutzt werden. Eine Anleitung hierzu würde also gegen die Forenregeln verstoßen."plan auf Blech" zuzugreifen geht auch über RDP mit der physikalisch vorhandenen Grafikkarte im Konsolenmodus. Bei Windows 10 nur 1 Benutzer gleichzeitig, bei Server zwei Benutzer, die beide Admin Rechte auf dem Server benötigen.
Gruß
its
@NordicMike:
Hm, offenbar bin ich etwas doof.
Der entfernte Rechner wurde neu gestartet, mein Mac ist per VPN eingebunden, der “normale RDP-Zugang” klappt problemlos und der User wurde nur getrennt (nicht abgemeldet). Ich habe jetzt einige setups getestet. Sowohl im UI von MacOS-RDP als auch in einer exportierten RDP-Datei setzte ich im Anschluss an die IP-Adresse /console, /Console, -console usw.
.. .er kann aber nicht verbinden. Habe ich nen Denkfehler? Oder geht das nur bei nem “ServerHost”?
Hm, offenbar bin ich etwas doof.
Der entfernte Rechner wurde neu gestartet, mein Mac ist per VPN eingebunden, der “normale RDP-Zugang” klappt problemlos und der User wurde nur getrennt (nicht abgemeldet). Ich habe jetzt einige setups getestet. Sowohl im UI von MacOS-RDP als auch in einer exportierten RDP-Datei setzte ich im Anschluss an die IP-Adresse /console, /Console, -console usw.
.. .er kann aber nicht verbinden. Habe ich nen Denkfehler? Oder geht das nur bei nem “ServerHost”?
Ich hoffe nicht.
Der entfernte Rechner wurde neu gestartet, mein Mac ist per VPN eingebunden, der “normale RDP-Zugang” klappt problemlos und der User wurde nur getrennt (nicht abgemeldet). Ich habe jetzt einige setups getestet. Sowohl im UI von MacOS-RDP als auch in einer exportierten RDP-Datei setzte ich im Anschluss an die IP-Adresse /console, /Console, -console usw.
.. .er kann aber nicht verbinden. Habe ich nen Denkfehler? Oder geht das nur bei nem “ServerHost”?
Gedacht war nur für einen Server (bis 2008). Ab Werk geht da beim Client (zum Glück) nichts.
Es müssen da ein paar bestimmte Vorarbeiten erfolgen und der Benutzer muss auch angemeldet sein. Aber aus den o.g. Gründen werde ich hier sonst nichts weiter dazu erklären.
Gruß
its
Der entfernte Rechner wurde neu gestartet, mein Mac ist per VPN eingebunden, der “normale RDP-Zugang” klappt problemlos und der User wurde nur getrennt (nicht abgemeldet). Ich habe jetzt einige setups getestet. Sowohl im UI von MacOS-RDP als auch in einer exportierten RDP-Datei setzte ich im Anschluss an die IP-Adresse /console, /Console, -console usw.
.. .er kann aber nicht verbinden. Habe ich nen Denkfehler? Oder geht das nur bei nem “ServerHost”?
Es müssen da ein paar bestimmte Vorarbeiten erfolgen und der Benutzer muss auch angemeldet sein. Aber aus den o.g. Gründen werde ich hier sonst nichts weiter dazu erklären.
Gruß
its
