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.

@testperson Bislang lief es einwandfrei - etwa über einen Zeitraum von ca 2 Jahren. Daher gehe ich davon aus, dass sich jetzt irgendetwas geändert hat, was zu den beschriebenen Problemen führt. Ich habe gerade mal einiges an Software runtergehauen was ggf. zu Konflikten führen kann. Mal sehen ob das abhilfe schafft. Alternativ setze ich am Wochenende neu auf, falls wir nicht noch überraschend die Lösung finden. Was ist das für ein NAS und wie ist es angebunden? Das kann Hyper-V ebenfalls ganz schön aus dem Tritt bringen. Die VMs _lagen_ auf dem NAS. Wie beschrieben habe ich sie da runtergeholt, weil die Performance nicht ausreicht um die Betriebsysteme aus dem Netzwerk heraus zu betreiben. VMs und HDDs der VMs liegen jetzt im lokalen Raid 0 des Servers. Die VMs selbst haben das Nas wiederum als Netzlaufwerk angebunden und kopieren Dateien nach der fertigen Bearbeitung auf das NAS. Beispielsweise: * Eine wawi erstellt rechnungs-pdfs etc, welche lokal auf C:\ gespeichert werden. Eine Batch kopiert diese PDFs regelmäßig auf das angebundene NAS. * Ebenfalls wird ein backup der Wawi-DB regelmäßig erstellt, lokal gespeichert und dann rüberkopiert. Reine netzwerk-Datentransfer-Aufgaben, keine Prozesse die über das Netzwerk gestartet werden oder ähnliches. * Dateien werden zum Konvertieren aus dem Netzwerk rüberkopiert, transcodiert und zurück-kopiert. Das OS der Maschinen ist also absolut unabhängig vom NAS. Es handelt sich dabei um ein QNAP TS 669 Pro. Gruß

@djmaker das stimmt. Ursprünglich war die Lokale festplatte ausschließlich für das OS gedacht. Die VMs lagen eigentlich auf dem angeschlossenen NAS. Es hat sich aber herausgestellt, dass die Geschwindigkeit der Datenübertragung nicht ausreicht, sodass die Dienste ihre Daten nicht schnell genug abspeichern können wenn die Daten übertragen werden müssen. Also mussten die Daten der VMs rüber wandern. Im selben Atemzug sind dann 2 weitere Festplatten eingezogen, um den Speicherplatz zu erweitern. Aus kostengründen ist die Lösung für den Moment noch so. Das eventuelle Drama hält sich in grenzen, da die virtuellen Maschinen sämtliche Daten ihrerseits ebenfalls auf dem NAS ablegen und nur das OS der VMs lokal betrieben wird. Zur Sache: Ich habe gestern die Kiste neu gestartet und dabei ist mir folgendes aufgefallen: Es scheint sich um zwei unterschiedliche Probleme zu handeln, bezüglich der abstützenden virtualisierung und dem aufhängen beim Neustart. Nach dem Kaltstart des Servers ist dieser wieder korrekt hochgefahren und die virtualisierung lief ohne Probleme wieder an. Ich habe auf Updates geprüft und den Server sicherheitshalber noch einmal durchgestartet. (durchstarten wollen) Er ist beim Neustart wieder hängen geblieben. Es scheint also so zu sein, dass sich der Server grundsätzlich beim Neustart aufhängt. Gleichzeitig ist es so, dass die Virtualisierung alle Nase lang wie oben beschrieben in die Fritten wandert. Ich vermute fast, dass ich um ein neuaufsetzen nicht herumkomme. Aber zuerst mal die versprochenen Fakten: Windows Server 2016 updates stets auf Stand. (v 10.0.14393 Build 14393) Hyper-V Manager 10.0.14393.0 Management Console 3.0 Version 1607 Hardware: ProLiant DL360 G7 BIOS Version: HP P68, 16.08.2015 Ereignisprotokoll: Kritisch 05.11.2019 16:12:36 Microsoft-Windows-Kernel-Power 41 (63) Das System wurde neu gestartet, ohne dass es zuvor ordnungsgemäß heruntergefahren wurde. Dieser Fehler kann auftreten, wenn das System nicht mehr reagiert hat oder abgestürzt ist oder die Stromzufuhr unerwartet unterbrochen wurde. Kritisch 05.11.2019 15:02:47 Microsoft-Windows-Kernel-Power 41 (63) Das System wurde neu gestartet, ohne dass es zuvor ordnungsgemäß heruntergefahren wurde. Dieser Fehler kann auftreten, wenn das System nicht mehr reagiert hat oder abgestürzt ist oder die Stromzufuhr unerwartet unterbrochen wurde. Kritisch 27.10.2019 07:13:24 Microsoft-Windows-Kernel-Power 41 (63) Das System wurde neu gestartet, ohne dass es zuvor ordnungsgemäß heruntergefahren wurde. Dieser Fehler kann auftreten, wenn das System nicht mehr reagiert hat oder abgestürzt ist oder die Stromzufuhr unerwartet unterbrochen wurde. Kritisch 21.10.2019 16:36:21 Microsoft-Windows-Kernel-Power 41 (63) Das System wurde neu gestartet, ohne dass es zuvor ordnungsgemäß heruntergefahren wurde. Dieser Fehler kann auftreten, wenn das System nicht mehr reagiert hat oder abgestürzt ist oder die Stromzufuhr unerwartet unterbrochen wurde. Kritisch 08.09.2019 15:10:07 Microsoft-Windows-Kernel-Power 41 (63) Das System wurde neu gestartet, ohne dass es zuvor ordnungsgemäß heruntergefahren wurde. Dieser Fehler kann auftreten, wenn das System nicht mehr reagiert hat oder abgestürzt ist oder die Stromzufuhr unerwartet unterbrochen wurde.

\o/ Einen allerbesten wunderguten Morgen alle miteinander.

Hi Jan, ich habe zwischenzeitlich alle Dienste "von Hand" beendet und mich dann nochmal an einem Neustart versucht. Leider ist der Server trotzdem hängengeblieben und hängt jetzt im "starte neu"-modus herum. Die Remotedesktopverbindung funktioniert zwar noch bis dahin, aber leider habe ich jetzt keinen Einfluss mehr auf den Server. Sobald ich zur Maschine komme starte ich die Karre neu, dann gibts infos zu den Eventlogs. Die Festplatten laufen im eingebauten Array als Raid 0. Darauf liegen sowohl OS als auch Maschinen und Storage der Maschinen. Das OS ist aktuell, ebenso die Treiber. Firmware müsste ich prüfen, aber da mir gerade der Einfluss auf die Maschine fehlt muss ich auch hier nachliefern. Ob die Dienste der VM noch laufen prüfe ich beim nächsten mal wenn die Karre abschmiert. Es wirkt auf mich so, als würde der Virtualisierungsdienst abstürzen. -> Wenn ich den Hyper-V Manager öffne erscheint ja üblicherweise links die Baumstruktur: Server ->v-Host 1 ->v-Host 2 -> etc Diese Baumstruktur wird nicht angezeigt - weder der Server noch die Hosts darunter. Daraus schließe ich, dass der gesamte Dienst abgestürzt ist. Einige virtualisierungsprozesse liefen allerdings noch als ich diese überprüft habe. Ich habe sie von Hand beendet - das hatte allerdings keinen Einfluss auf das System oder die Darstellung. Beim erneuten öffen des Hyper-V Managers blieb die Anzeige unverändert. Mich irritiert, dass der Server sich beim Neustart aufhängt. Irgendwas blockiert da das herunterfahren. Gruß Pinky

Guten Morgen zusammen, Bin der neue, ich soll hier tanzen. ich setzt schonmal Kaffee auf. -> Tag in die Runde. Gruß Pinky

Tag zusammen, ich habe seit kurzem ein Problem mit meiner Virtualisierung - vielleicht hat ja einer von euch eine Idee. Seit einiger Zeit wird keine Verbindung mehr zu meinen virtuellen Maschinen im Hyper-V aufgebaut. Das bedeutet, das Fenster zu den Maschinen öffnet sich nicht mehr. Dieses Problem tritt nur sporadisch auf und lässt sich durch einen Neustart beheben. Der Hyper-V Manager funktioniert ganz normal, der Status aller Maschinen wird angezeigt und diese laufen normal. Sie tun nachweislich ihre Arbeit. Bei einem doppelklick auf die Maschinen, (oder rechtsklick "verbinden") tut sich aber nichts -> das Fenster öffnet sich nicht. Kleine Korrektur: Ich habe den Hyper-V Manager mal geschlossen und wieder geöffnet: Anschließend öffnet sich der Hyper-V Manager aber keine Maschinen werden angezeigt. Ob diese in dem jetzigen Zustand noch laufen kann ich im moment nicht sagen. Begleiterscheinung: Wenn ich nun versuche die Kiste neu zu starten hängt sich der Server beim Neustart auf. (hängt im blauen "wird neu gestartet" screen). Ein Kaltstart setzt alles zurück auf Anfang, die Maschinen sind dann zugreifbar. Bis irgendwann dieses Problem wieder auftritt. Dauert einige Tage, manchmal Wochen. In dieser Zeit verbinde ich mich täglich mehrfach zu den Maschinen. Jemand eine Idee, oder ähnliche Erfahrungen gemacht? Gruß Pinky