Pinky__

Tag zusammen, ich würde gerne einen ThinClient verwenden um von ihm aus auf eine im internen netzwerk liegende virtuelle Maschine zuzugreifen. Die virtuelle Maschine liegt auf einem Windows Server 2016, soll aber ggf. in Zukunft auf einen Ubuntu-Server transferiert werden - beide jedoch im internen Netzwerk. Der ThinClient soll also in-house mit Tastatur, Maus und Bildschirm ausgerüstet, eine kostengünstige alternative sein. Die Rechenpower liegt dann auf dem Server. Frage: Da die meisten ThinClients nur etwa 2GB flash-Speicher haben - welches Betriebssystem installiere ich, auf den ThinClients, damit ich mich damit zu den virtuellen Maschinen verbinden kann? Es reicht im Grunde, dass auf dem ThinClient die Eingabemaske für die Remotedesktopverbindung gestartet wird. Der Rest passiert ja woanders. Welches OS empfehlt ihr? Gruß

Tag zusammen, ich versuche gerade von einem externen Rechner aus eine RDP-Verbindung zu einem Linux-System herzustellen, welches unter Hyper-V läuft. Im Einsatz ist eine Fritz-Box, auf der die Portfreigabe bereits erstellt ist. Hier habe ich eine Portfreigabe von 3389 an 3389 eingerichtet und greife auf diesem Wege auf den Hyper-V Server selbst zu. Das funktioniert einwandfrei auch von extern. Eine weitere Portfreigabe habe ich von Port 1000 an 3389 erstellt, damit die RDP-Verbindung über den Port 1000 an die Gastmaschine erfolgen kann. -> Das funktioniert extern derzeit leider noch nicht. Vom Server selbst kann ich per RDP-Verbindung auf die Linux Maschine zugreifen. xrdp ist also korrekt installiert und technisch gibt es hier kein Problem. Als Adresse verwende ich in diesem Fall natürlich den Hostnamen, der im internen Netzwerk einwandfrei aufgelöst werden kann. (Gerade nochmal den umgekehrten Fall getestst: Auch über die externe IP funktioniert die Verbindung vom Server aus: externe-url.com:1000 -> Funktioniert) Von außen allerdings nicht. Ich kann mir auch vorstellen, dass die Virtualisierung hier noch eine Rolle spielt. Hat jemand eine Idee worans liegen könnte? Gruß Pinky Edit: Oooookay, der Port 1000 ist im anderen (externen) Netzwerk gesperrt. Nix mit verbinden. Port 80 funzt, der ist logischerweise freigegeben. Mann ist das langsam. Aber lüppt. Gruß

Das klingt spannend. Auf die Teuren karten habe ich auch bereits zurückgegriffen. Meine ursprünglichen Karten sind schon nach ~1-2 Monaten in die Fritten gegangen. Vermutlich liegts aber an Anwendungsfall, ich habe damals ein DNLA-Server darüber betrieben, der schreibt natürlich recht viel rum. Und dann mit den billigen Karten... Mit einer Lebensdauer von 2 Jahren könnte ich durchaus leben. Aber der read-only modus klingt natürlich nach einer extrem coolen Lösung. Danke für den Tip! Gruß Pinky

Danke euch für die vielen guten Vorschläge, das schonmal vorab! Ein gebrauchter Thin-Client... Daran hatte ich nicht gedacht. Und in der Tat liegen die bei etwa 10-20 glänzenden Talern, was durchaus akzeptabel ist. Geplant ist das Projekt auf rein privater Basis. Das bedeutet es werden im privathaushalt 1-2 rechner aufgestellt die nach möglichkeit den im Serverraum verbauten Hyper-V als Resource nutzen. Das hier ebenfalls angeschlossene NAS kann zur Datensicherung dienen und da das System immer läuft kann man also von überall auf seinen eigenen persönlichen kram zugreifen und im optimalfall für die einzelnen Anwendungsfälle auch mal fix die Box wechseln. (Büroarbeit->Bürobox, Kind1->Kind1Box, Kind2->Kind2Box, Zip-File öffnen oder gar exe bei der man sich nicht sicher ist-> TrashBox) Auf ebendiese Boxen lässt sich per RDP dann auch von außerhalb des Netzwerkes zugreifen da diese IMMER verfügbar (online) sind. Der eigentliche Rechner bleibt also nur Handlanger, ein Werkzeug um drauf zuzugreifen wenn man so will. Daher die Idee "nur" einen Raspberry einzusetzen. Die Problematik mit der Wartbarkeit eventuell größerer Systeme stellt sich bei mir also nicht. Dennoch stimme ich zu: Professionell würde ich die PIs auch nicht unbedingt einsetzen. Auch meine Erfahrungen damit gehen in die Richtung, dass die PIs gerne mal ausfallen bzw. die SD-Karte hinüber ist. Privat kein Thema: Im Optimalfall hat man noch eine ersatzkarte fertig vorbereitet in der Schublade und gut. Auf professioneller Basis sind richtige ThinClients glaube ich die bessere wahl. Sehr spannend fand ich in dem Zusammenhang die Igel-Sticks. Aber auch hier ist mir direkt aufgefallen: Wirklich "einfacher" sind die in der tat auch nicht. Hier eröffnet sich wieder ein universum an Möglichkeiten die sicher auch den Preis rechtfertigen. "Short and simple" ist aber auch was anderes. Auch hier müssen experten ran um die dinger zu konfigurieren. Mit Linuxkenntnisen sollte also ein wie auch immer geartetes System am einfachsten aufzusetzen sein - die Plattform ist dabei erstmal egal. Privat wirds für mich nun testweise der Raspberry. Wenn der sich weiter so zickig anstellt wie ich es gewohnt bin und weshalb ich ihn in die Kabelkiste geworfen habe beim letzten mal als mir die 3. SD-Karte kaputtgegangen ist, dann ersetze ich ihn durch einen gebrauchten Thin-Client. Der Weg erscheint mir absolut gangbar. Insofern schonmal vielen Dank allen für die absolut konstruktive(!) und hilfreiche Diskussion zum Thema. Gruß Pinky

Im moment bin ich - der Einfachheit halber, dafür das ganze unter einer einfachen Linux distro aufzusetzen und wie oben schon erwähnt die rdp beim autologon auszuführen. Die alternative erscheint mir recht beta und zudem sind Wartungen oder kleinere Probleme bei einer normalen Linux distro schneller gemacht, weil alles aus der Westentasche kommt. Solange nicht noch irgendwer mit ner standardlösung für diesen Anwendungsfall um die Ecke kommt, würde ich das mal testen am Wochenende.

Klingt simpel. Das ist zumindest auch die Lösung die mir das Internet bislang ausgespuckt hat.

Die USB-Grakas habe ich in einigen Bereichen im Einsatz - die sind nicht schlecht und funktionieren tadellos auch unter Linux. (Wir reden hier natürlich über Office Anwendungen) Der Igel-Stick klingt spannend, kostet aber natürlich auch eine Kleinigkeit. Bei dem Preis kann man im Grunde gleich einen herkömmlichen Thin-Client nehmen. Spannend ist das ganze mit dem Pi, weil die entstehenden Kosten denkbar gering sind. Eine Software die die Verbindung zur virtuellen Maschine herstellt ist schnell installiert und dass der PI hin und wieder etwas Pflege braucht ist vertretbar. (Wir reden hier vom Privaten Umfeld, nicht von einem produktiven Einsatz) Aber wenn ich euch richtig verstehe, gibt es die von mir beschriebene Wunschlösung so nicht: Eine Software die auf dem Raspberry bootet und direkt in einen Windows-Remotedesktop verbindet? Gruß Pinky

Tag zusammen, ich überlege gerade, ob es sinnvoll sein könnte einen Raspberry PI als ThinClient einzusetzen und ob die auf dem Markt befindliche Hard-/ und Software für meinen Anwendungsfall ausreichend bzw. optimal ist. Das Thema wird über die verschiedenen Kanäle recht breit diskutiert und ist oft umgesetzt worden - mir fällt es hier aber schwer die einzelnen Lösungen richtig einzuordnen. Vielleicht könnt ihr mir dazu ein wenig Hilfestellung geben. Was ich erreichen möchte ist simpel: Maus, Tastatur, Monitor und Raspberry bilden ein Terminal von dem aus man Arbeiten kann. Im Idealfall loggt man sich so früh wie möglich direkt auf einer virtuellen Maschine im eigenen Netzwerk ein und bemerkt gar nicht, dass das Betriebssystem nicht auf dem lokalen rechner liegt. Bei meiner Erfahrung mit RDP sollte das prinzipiell möglich sein, das läuft Erfahrungsgemäß recht flüssig. Gibt es ein Betriebssystem für den PI welches mir eine "Login-Maske" dieser Art anbietet? Im Optimalfall wäre natürlich eine "konfigurationsdatei" noch besser, die ausgelesen wird, sodass direkt beim Start in die virtuelle Maschine eingeloggt wird. Machbar? Danke euch Gruß Pinky

o/ Licht bleibt aus. Koche Kaffee im Dunkeln. Guten Morgen zusammen.

Ja, ars***kalt. Selbst hier im Büro. Mäh :/

Der Server selbst ist ein HP ProLiant, im Originalzustand. Keine anderen Bauteile verbaut. Einen Servicevertrag gibt es nicht und der allerneuste ist es auch nicht mehr - insofern: Nein, leider nicht. Vermutest du ein Hardwareproblem? Basierend auf den Fehlermeldungen google ich gerade etwas durch die Gegend und bin hierauf gestoßen: https://community.spiceworks.com/topic/2104499-jan-2018-windows-updates-kb4056898-causing-hyper-v-guests-crash Das hier beschriebene Problem ähnelt meinem. Das betroffene Update ist bei mir allerdings nicht zu finden. Dennoch finde ich den Ansatz sinnvoll, die Updates zurückzurollen. Das Problem besteht noch nicht allzu lange und Irgendwie muss es seinen Weg hinein ins system gefunden haben. Hier verdächtige ich ebenfalls die Updates. Also rolle ich mal 3-4 Monate zurück. Mal sehen ob das hilft. Anschließend starte ich die Karre neu. Mal sehen ob sie dann wieder komplett abglitscht.

o/ Morgen zusammen. Server wieder abgeschmiert und schon bin ich wieder hier zugange. Die Woche könnte nicht schöner anfangen. Na was solls, schönen Wochenstart euch anderen. Edit: Ahja, Licht an, Koche jetzt Kaffee für alle.

Guten Morgen zusammen, in der Zwischenzeit konnte ich etwas konkretere Informationen sammeln. Heute morgen ist das System wieder abgestürzt. Derzeit befindet sich das System in dieserm abgestürzten Modus. -> Ich kann keine Verbindung zu einer VM aufbauen -> Die VMs haben Ihren Dienst eingestellt --> Offenbar ist dies passiert nachdem ich mich zu den VMs verbinden wollte. Bis dahin liefen sie. --> Der noch geöffnete Server Manager zeigt mir an, dass einige von den Maschinen Prozessorlast haben. (3% schwankend) Die Dienste die darauf laufen sind aber nicht verfügbar. Beim Versuch auf die VMs zu verbinden werden folgende Logs geschrieben: .Net Runtime Anwendung: VmConnect.exe Frameworkversion: v4.0.30319 Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet. Ausnahmeinformationen: Microsoft.Management.Infrastructure.CimException bei Microsoft.Management.Infrastructure.Internal.Operations.CimSyncEnumeratorBase`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].MoveNext() bei System.Linq.Enumerable+WhereSelectEnumerableIterator`2[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089],[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].MoveNext() bei Microsoft.Virtualization.Client.Management.Server.LoadOSInfo() bei Microsoft.Virtualization.Client.ConnectionHelper.ConnectServer(Microsoft.Virtualization.Client.InformationDisplayer, System.String, Boolean, Microsoft.Virtualization.Client.Common.IUserPassCredential) bei Microsoft.Virtualization.Client.ConnectionHelper.TryGetVirtualMachinesInternal(System.String, Microsoft.Virtualization.Client.Common.WindowsCredential, Mode, System.String, System.Guid, Microsoft.Virtualization.Client.Management.IVMComputerSystem ByRef, System.Collections.Generic.List`1<System.String> ByRef, System.Exception ByRef) bei Microsoft.Virtualization.Client.InteractiveSession.CommandLineParser.TryParse(System.String[], Microsoft.Virtualization.Client.InteractiveSession.RdpConnectionInfo ByRef) bei Microsoft.Virtualization.Client.InteractiveSession.VmisApplicationContext.TryParseCommandLine(System.String[]) bei Microsoft.Virtualization.Client.InteractiveSession.Program.Main(System.String[]) sowie Application Error Name der fehlerhaften Anwendung: VmConnect.exe, Version: 10.0.14393.0, Zeitstempel: 0x5789927d Name des fehlerhaften Moduls: KERNELBASE.dll, Version: 10.0.14393.3269, Zeitstempel: 0x5d9133fb Ausnahmecode: 0xe0434352 Fehleroffset: 0x0000000000034c48 ID des fehlerhaften Prozesses: 0x4c58 Startzeit der fehlerhaften Anwendung: 0x01d598512a86b819 Pfad der fehlerhaften Anwendung: C:\Windows\system32\VmConnect.exe Pfad des fehlerhaften Moduls: C:\Windows\System32\KERNELBASE.dll Berichtskennung: 627727eb-213c-44ed-a882-43e6c2f9c049 Vollständiger Name des fehlerhaften Pakets: Anwendungs-ID, die relativ zum fehlerhaften Paket ist: Diese beiden Fehlermeldungen wiederholen sich bei jedem Versuch zu einer der Maschinen zu verbinden. Die Maschine bei der der Fehler vorhin auftrat ist vorgestern aufgesetzt worden und wurde gestern eingerichtet. Sie ist also "brandneu". Ein paar Minuten vor dem ersten Verbindungsversuch findet sich im Log noch folgende Fehlermeldung: DeviceSetupManager Fehler beim Staging von Metadaten. Ergebnis=0x8007000D für Container "{00000000-0000-0000-FFFF-FFFFFFFFFFFF}". Jemand eine Idee was das Problem sein könnte? Gruß Edit: (Nachtrag) Ein vielleicht nicht ganz unerhebliches Detail: In der Ergebnisanzeige der Logs bekomme ich ebenfalls Fehler ausgeworfen. Beim Versuch die Fehlermeldungen unter - Server --> Hyper-V oder --> Remotedesktopdienste anzuzeigen bleibt das Fenster leer (grau) und ich bekomme ein Popup: "Abfragefehler" Mindestens ein Protokoll in der Abfrage enthält Fehler. Die angezeigten Ergebnisse sind Teilergebnisse. Einträge die wiederhergestellt wurden lauten: Microsoft Windows Hyper-V High Avaiability Admin: Der Angegebene Kanal wurde nicht gefunden Microsoft Windows Hyper-V Integration Admin: Der Angegebene Kanal wurde nicht gefunden

Guten Morgen zusammen! Schon Donnerstag! Schönen Tag allen zusammen.

Produktiv im privaten Umfeld.