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.
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!
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.
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?
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.
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.
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...
