Hi. Gibt es eine Möglichkeit, einen Windows 10 Pro PC zeitgleich mit mehreren Usern parallel Remote und Lokal zu nutzen? Bei Windows Remote Desktop ist eine lokale Nutzung nicht möglich, sobald man Remote darauf zugreift. Der lokale Benutzer soll aber weiter arbeiten können, auch wenn der PC remote durch einen zweiten Account genutzt wird. Ich weiß auch nicht, ob mehrere Remotesitzungen zeitgleich möglich sind. Außerdem hätte ich gerne auch die Möglichkeit, mit Linux- und Android Clients zuzugreifen. Kennt ihr da was?
Tom schrieb: > Bei Windows Remote Desktop ist eine lokale Nutzung nicht möglich, sobald > man Remote darauf zugreift. suche mal nach "concurrent session patch Win10"
Das ist genau das was ein Terminal Server macht und daher in den
Nicht-Server Varianten normalerweise nicht enthalten. Der "concurrent
session patch" ändert genau das - allerdings ist das keine offiziell
unterstützte Funktion sondern eine Bastellösung ("Hack").
Wenn es funktoniert, gut - wenn nicht oder wenn M$ den Hack weg-updated
muss man halt sehen wo man bleibt...
Tom schrieb: > Der lokale Benutzer soll aber weiter > arbeiten können der Windows Terminal Server kann Multi-User schon seit Jahrzehnten, aber den Server auch lokal zu benutzen, war noch nie eine brauchbare Idee - zu viele Möglichkeiten, alle aktiven Remote-Benutzer mit in den Abgrund zu reissen. Georg
Georg schrieb: > der Windows Terminal Server kann Multi-User schon seit Jahrzehnten, aber > den Server auch lokal zu benutzen, war noch nie eine brauchbare Idee - > zu viele Möglichkeiten, alle aktiven Remote-Benutzer mit in den Abgrund > zu reissen. wie meinst du da? Alles was man lokal kann, kann man auch remote machen. Ich sehe da kein Unterschied.
Den Ausschalter drücken kann man nur lokal. An solche Dinge sollte man vor allem dann denken, wenn man mit absoluten DAUs zu tun hat.
Peter II schrieb: > Alles was man lokal kann, kann man auch remote machen Nein, nicht beim Terminal Server. Sonst könnte ja in einer Firma jeder Mitarbeiter den Betrieb lahmlegen, indem er einfach den Server herunterfährt. Das ist eben die Besonderheit des TS, dass die Sessions weitgehend abgekapselt sind. Das Konzept ist auch in vielen Einsätzen bewährt, teilweise mit hunderten von Usern. Dass du das nicht kennst ändert daran ja nichts. Georg
Shutdown -f kann auf dem TS nicht jeder? naja, gibt ja nich umsonst sowas wie Gruppenrichtlinien... egal, ich kannte diese Lösung für Windows XP, damals war dies noch manuell zu tätigen Schön zu wissen, dass auch Win7++ das bieten... Danke für den Tip!
:
Bearbeitet durch User
Georg schrieb: > Nein, nicht beim Terminal Server. Sonst könnte ja in einer Firma jeder > Mitarbeiter den Betrieb lahmlegen, indem er einfach den Server > herunterfährt. Das ist eben die Besonderheit des TS, dass die Sessions > weitgehend abgekapselt sind. Das Konzept ist auch in vielen Einsätzen > bewährt, teilweise mit hunderten von Usern. Dass du das nicht kennst > ändert daran ja nichts. das ist Unsinn. Man jeden Nutzer zuweisen ob er den PC herunterfahren kann oder nicht. Das hat nicht mit Remote oder Lokal zu tun. Ein normaler Nutzer darf auch einen Server lokal nicht herunterfahren.
Mike B. schrieb: > naja, gibt ja nich umsonst sowas wie Gruppenrichtlinien... Normalerweise werden Terminal Server von Firmen-Admins verwaltet, und wenn die ihren Verstand beieinander haben, so restriktiv, dass die User keinen Schaden anrichten können. Typisch ist die Sessions im "Kiosk" Mode einzurichten, d.h. z.B. der Lagerarbeiter kann nur die Lagerverwaltung benutzen, er kann kein anderes Programm starten (und das eine startet gleich automatisch). So funktioniert der angeschlossene PC wie früher ein Terminal am Grossrechener, und deswegen heisst das Ding auch Terminal Server. Das Konzept scheint hier völlig unbekannt zu sein, war aber in der Geschäftswelt weit verbreitet, aus Sicherheitsgründen und auch weil es veralteten Rechnern zu einem verlängerten Leben verholfen hat - nur der Server muss genügend Leistung für die parallel laufenden Programme haben, als Client reicht schon ein Windows3-PC. Ähnlich ist das Konzept mit Thin Clients, nur beruhen die auf Browser-Technik. Ein weiterer Riesenvorteil ist, dass man neue Softwareversionen nur auf dem Server installieren muss und nicht auf den Clients. Wahrscheinlich geht die Technik deshalb unter, weil MS usw. gnadenlos das Rechnen in der Cloud favorisieren und Lösungen innerhalb der eigenen Firma nicht gerne sehen. Georg
Ein Haken an der Sache ist die Lizenzfrage. Das ist nicht kostenlos, jeder Client eines Terminal Servers kostet Geld. Die Terminal Server Methode geriet etwas in den Hintergrund, weil man das gleiche Ziel auch mit Virtualisierung erreichen kann, ohne sich aber aber die etwas eigene Installationsmimik von Anwendungen auf dem TS antun zu müssen. Virtualisierte PCs sind von Natur aus vollständig entkoppelt. Die Lizenzfrage stellt sich dabei freilich ebenfalls.
:
Bearbeitet durch User
Hi. Ich wollte es nicht im Firmenumfeld betreiben, sondern zuhause. Und da habe ich auf dem "Hauptrechner" Windows 10 Professional. Auf dem Rechner ist auch meine Entwicklungsumgebung und Photoshop u.ä. installiert. Diese Umgebung will ich mit anderen Rechnern remote verwenden. Idealerweise auch mit Linux bzw Android Client. (Nettop, Tablet, TV Box) Der große Standrechner ist auch der einzigste Desktop PC, der noch bei uns existiert. Daher möchte ich auch dann Zugriff auf den Rechner, wenn z.B. meine Frau da Grußkarten designt o.ä.
Wie bereits gesagt, unterstützt Windows Server dieses Nutzungsszenario und die wird häufig im Unternehmen eingesetzt. Und weil Microsoft das für ein ausschließlich professionelles Feature hält, halten die ordentlich die Hand auf. Lizenzen für den Server und jeden einzelnen potentiellen Client sind imho notwendig, wenn das ganze legal betrieben werden soll. Alternative 1: Billige Windows Lizenzen besorgen, Maschinen auf Virtual Box installieren und über RDP. VB hat ja von sich aus auch einen RDP Server zur Verwendung. Müsste man wegen Lizenzrecht noch mal ansehen. Normales Windows auf virtuellen Maschinen ist wahrscheinlich auch von MS unerwünscht... Alternative 2: Ansonsten mal sehen ob die Zielsoftware nicht einfach unter Linux bzw. Wine läuft. Dann spart man sich den ganzen MS Lizenzwahn. Und hat auch viele etablierte Möglichkeiten der Remote Arbeit. Letztendlich kommt es darauf an, wie sehr man Lizenzen akzeptiert. Sonst kann man sich mit halblegalen Patches aus dem Netz jede Funktion in Windows freischalten.
Tom schrieb: > Außerdem hätte ich gerne auch die Möglichkeit, mit Linux- und Android > Clients zuzugreifen. > > Kennt ihr da was? Einen Xserver an an den Start bringen. http://www.straightrunning.com/XmingNotes/ Installers are for Windows 10/8/7/Vista/XP (+ Server 2012/2008/2003). -----
[$omen] schrieb: > Einen Xserver an an den Start bringen. Bei X werden die Begriffe "Client" und "Server" in etwas anderer Art und Weise genutzt, als Du Dir vorzustellen scheinst. Mit einem X-Server, der auf einem Windows-Rechner läuft, kannst Du jedenfalls das gewünschte Szenario (Fernbedienung dieses Windows-Rechners) noch nicht mal ansatzweise umsetzen.
Rufus Τ. F. schrieb: > Szenario (Fernbedienung dieses Windows-Rechners) noch nicht mal > ansatzweise umsetzen. ? Du meldest dich eg. ueber ssh an deinem Windowsrechner an startest dort aus der ferne als lokaler Windowsnutzer einen xserver und exportierst dessen Display. Der ist dann client zum lokalen X. $ ssh ...@... # startx --:displaynummer & # export DISPLAY=:displaynummer # xhost +[erlaubte ip-addresse] --- (# startx /explorer32xy.exe --:displaynummer) Weshalb sollte es nicht moeglich sein, schnelle Verbindung vorausgesetzt das mit dem dicken Brocken explorer-shell zu machen?
[$omen] schrieb: > Weshalb sollte es nicht moeglich sein, weil dann die Anwendung nicht auf dem Server läuft.
Peter II schrieb: > weil dann die Anwendung nicht auf dem Server läuft. Die laeuft dort wo sie gestartet wurde, wo sollte sie denn sonst laufen. $ ssh ...@... das sollte klar sein funktioniert unter Windows nat. so nicht: # startx --:displaynummer & # export DISPLAY=:displaynummer # xhost +[erlaubte ip-addressen] Aber so holt man sich im Prinzip ein Display vom fremden X auf dem Windowsrechner entsprechend zu ersetzen; >"C:\Program Files\Xming\Xming.exe" -multiwindow -clipboard -... anstelle "startx --:displaynummer &" usw. Habe aber kein Windows, werde dem nicht jetzt nicht weiter nachgehen.
Das X-Protokoll war für lokale Netzwerkverbindungen gedacht, da wird fast nichts gecached und jeder X-Call läuft auf ein Frage-Antwort-Paket-Päärchen raus. Das war über DSL oder gar Modem schon immer sehr zäh. Es gibt zwar ein paar Erweiterungen dagegen (zB. LBX), aber "dank" immer bunterer und fluppiger Toolkits, die quasi alles selbst rendern und damit viel Bitmaps übertragen müssen, macht das auch heute trotz geringerer Latenzen und höherer Bandbreite wenig Spass. MS kam mit dem Remote-Desktop viel später als X, konnte aber immerhin das gleich beim Design berücksichtigen. Es gibt zwar unzählige Sonderlösungen/VPN-Wrapper, um das Remote-Desktop-Protokoll "sicher" zum Terminalserver zu bekommen (Citrix Receiver, Juniper, ...), aber das ist halt die übliche MS-Taktik, um die Industriepartner froh zu machen ;)
Scelumbro schrieb: > Müsste man wegen Lizenzrecht noch mal ansehen. Das ist ziemlich komplexes Thema, weil bei verschiedenen Windows-Desktop Lizenzen recht verschieden. MS drängt die Leute heftigst dazu, Dauerzahler per Software Assurance zu werden, das öffnet manche Türen. Wenn MS Office drauf ist, dann ist das ausserdem zusätzlich zu betrachten. Es ist nicht leicht und nicht billig, dabei legal und geistig gesund zu bleiben. Für solche Lizenzfragen gibts nicht ohne Grund eine zweitägige Schulung.
:
Bearbeitet durch User
[$omen] schrieb: > $ ssh ...@... > # startx --:displaynummer & > # export DISPLAY=:displaynummer > # xhost +[erlaubte ip-addresse] Steinzeit. Langsam. Umständlich. Die Linux-Alternative zum Termninalserver ist x2go
Tom schrieb: > Ich weiß auch nicht, ob mehrere Remotesitzungen zeitgleich möglich sind. Das ist möglich.
Scelumbro schrieb: > Alternative 2: Ansonsten mal sehen ob die Zielsoftware nicht einfach > unter Linux bzw. Wine läuft. Das wird so wahrscheinlich nicht funktionieren.
Bernd K. schrieb: > [$omen] schrieb: >> $ ssh ...@... >> # startx --:displaynummer & >> # export DISPLAY=:displaynummer >> # xhost +[erlaubte ip-addresse] > > Steinzeit. Langsam. Umständlich. funktioniert aber > > Die Linux-Alternative zum Termninalserver ist x2go x2go stürzt bei mir relativ oft ab (verbindungsabbruch, session bleibt bestehen), wenn ich java gui's auf dem server benutze. ansonsten ists recht nett. aber das ist OT.
Hoppelpott schrieb: > Was genau sind Wrapper? Man will keinen Terminalserver frei aus dem Internet zugänglich haben (obwohl wir das neulich bei einem Neukunden so vorgefunden haben...). Deshalb braucht es irgendeine Variante des VPNs, wo der User schon vorher sich authentifizieren soll (zB. Zwei-Faktor, Token, etc.). Die MS-eigenen VPN-Varianten sind für den DAU nicht ganz einfach einzurichten (PTP, CHAP, PEAP, TLS, ICE, Ojemine). OpenVPN geht schon (braucht ja nur ein Programm und Zertifikat), ist aber in einer reinen MS-Monokultur auch eher ungewöhnlich. Und überhaupt muss es ja sicher sein, da kann man so ein Opensource-Gefrickel nicht nehmen. Also kauft die IT sich da was für viel Geld von namhaften Firmen ein. Da gibts dann zB. eine Webseite, auf der man sich einloggt (mit/ohne Bestätigungsmail/SMS, mit/ohne Token). Dann darf man sich supertolle Anwendung runterladen, die dann mit einem Klick im Webinterface gestartet wird und die macht dann "irgendwie", aber jedenfalls natürlich ganz sicher den Remote-Desktop auf. Manchmal lassen sich dann über den Tunnel auch noch Laufwerke verbinden, hängt von der Paranoia der IT ab ;)
c.m. schrieb: > verbindungsabbruch, session bleibt > bestehen Das ist ein Feature daß man Sitzungen jederzeit disconnecten und später wieder aufnehmen kann. Mit nacktem X-forwarding würde die Anwendung jedesmal einfach gekillt. > aber das ist OT. Naja, das Problem des OP wurde ja schon gelöst (Terminalserver-Lizenz kaufen), jetzt nachdem das also aus dem Weg ist können wir ja zum gemütlichen Teil des Threads übergehen und den ganzen Themenkomplex ungezwungen in einem weiter gefassten Bereich diskutieren.
:
Bearbeitet durch User
Georg A. schrieb: > Man will keinen Terminalserver frei aus dem Internet zugänglich haben > (obwohl wir das neulich bei einem Neukunden so vorgefunden haben...). > Deshalb braucht es irgendeine Variante des VPNs, wo der User schon > vorher sich authentifizieren soll (zB. Zwei-Faktor, Token, etc.). dann richtet man einfache den RDP-Gateway auf Basis vom IIS ein. Liefert alles MS mit. Läuft dann alles über HTTPS und Client Zertifikat.
Peter II schrieb: > dann richtet man einfache den RDP-Gateway auf Basis vom IIS ein. Liefert > alles MS mit. Läuft dann alles über HTTPS und Client Zertifikat. Alles viel zu unsicher und kostet gar nichts ;) Muss unbedingt was von Cisco, Juniper, Citrix etc. sein. Nicht meine Meinung...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.