dataKEKS

Na Du schaffst es aber immer wieder meine Hoffnung an das gute in der IT zu torpedieren *jammer*

Update: Egal was ich mache, und sei es manuell die alte MAC Adresse im Hyper-V für die VMs hinterlegen: die VMs erkennen bei mir immer eine neue Netzwerkkarte. Sicher kein Weltuntergang, aber für diejenigen, die eine feste MAC / IP brauchen ist es hoffentlich eine hilfreiche Info. Noch eine Auffälligkeit: Windows bindet nur das C: Laufwerk automatisch wieder ein, wenn die VMs wie in meinem Fall aber mehrere Laufwerke haben müssen diese noch händisch in der Datenträgerverwaltung wieder online geschaltet werden. Empfehlung meinerseits: VMs auf jeden Fall nach Neueinrichtung noch mal neu starten damit sie mit allen Partitionen / Laufwerken und korrekter LAN Verbindung einen clean boot erreichen kann Norbert

Sodele, jetzt konnte ich mich endlich dem Thema wieder widmen und kann folgendes berichten: Da ein Neustart unseres Haupt-Hyper-V im Tagesbetrieb bei den Usern nicht so toll ankommt habe ich die VMs auf einen kleineren, eigentlich nicht mehr benutzten Testserver ausgelagert, einen HPE MicroServer Egal ob ich ihn mit Server 2022 oder 2025 betreibe, die problematischen VMs haben das Problem nach Export auf dem eigentlichen und Import auf dem Testserver beibehalten, das spricht sehr für die Vermutung das wirklich in der Konfiguration ein Fehler steckt und nicht der ausführende Hyper-V das Problem ist. Somit war klar: Jetzt bekommen die beiden problematischen VMs mal eine neue Konfiguration, also VM im Hyper-V gelöscht, neu angelegt und dann die VHDs wieder eingebunden, LAN Konfiguration passend definiert (bei uns VLANs) und die VMs gestartet - funktioniert. Was nur quasi zu erwarten war: Für Windows sind es neue NICs, und damit musste ich noch die statische IP Adresse wieder eintragen. Werde das gleiche noch einmal probieren und vor dem Start der VMs noch die alte MAC Adresse händisch hinterlegen, aber das nur am Rande. Jetzt zum spannenden Teil: Neustart des Hyper-V ohne die VMs vorher herunter zu fahren: Es tut wieder, die VMs können problemlos wiederhergestellt werden ohne irgendeine Änderung am ausführenden Hyper-V Somit wissen wir jetzt schon einmal wie wir das Problem lösen können, wenn jetzt noch die NIC im Zuge der Neuanlage im Hyper-V nicht neu erkannt wird wäre das natürlich noch eine enorme Erleichterung Update folgt. Norbert

Jain, ich will ja sehen ob sie nach Neuanlage aus dem Status gespeichert wieder sauber hoch läuft. Norbert (der Dritte??)

Guten Morgen Norbert (herrlich so ein Gespräch auf Augenhöhe :-)), also empfiehlt der Kollege was ich mir auch schon überlegt hatte: VM neu anlegen und die VHDs der Original VM übernehmen. Werde ich heute Abend mal so ausprobieren, wenn ich unseren Hyper-V jetzt im Tagesbetrieb herunterfahre ist das selbst in den Faschingsferien äußerst ungern gesehen Update folgt Norbert (der aus BaWü)

Hallo Freunde des Hyper-V, ich verzweifle gerade im Zuge des Patchday an einem Hyper-V Problem für das ich einfach keine Lösung finde: Auf unserem Hyper-V (Windows Server 2022 Standard, HPE Proliant ML350 Gen10) laufen rund 20 VMs, darunter auch vier Terminalserver. Alle VMs wurden auf genau diesem Server überhaupt erst in Hyper-V erzeugt und installiert. Wir reden von rein lokalem Speicher, keiner wiederhergestellten Maschine, aber sie legt ein wirklich seltsames Verhalten an den Tag. Wenn wir - so wie heute - die Updates vom Patchday installieren fahren wir nicht extra alle VMs herunter sondern überlassen das dem Hyper-V im Zuge des Neustarts. Bis auf einen TS (auch Windows Server 2022 Standard) klappt das auch mit wirklich allen VMs wunderbar, nur ein TS tanzt aus der Reihe: Er hat den Status gespeichert und kann nicht mehr gestartet werden. Wenn wir versuchen die VM zu starten erhalten wir die Fehlermeldung Fehler beim Versuch die ausgewählten virtuellen Computer zu starten, nur ein gespeicherten Status verwerfen ermöglicht uns die Maschine wieder zu starten :-( Alle Systeme laufen gegen den gleichen, internen WSUS und sollten somit den gleichen Patchstand haben, aber aus irgendeinem mir nicht erfindlichen Grund tanzt eben ein Server aus der Reihe.... Kennt jemand dieses Verhalten und hat eine Lösung für mich? Tante Google hat mir bislang nichts hilfreiches geliefert :-( Grüße aus BaWü Norbert

Also: SSH und SFTP mit einem Windows Server sind gar kein Problem, sowohl mit der von Microsoft direkt mitgelieferten Version beim Windows Server 2025 als auch bei den Vorgängern (und da als optionales Feature). Ich versuche nicht einen kompletten Roman zu schreiben sondern nur ein paar wichtige Stichworte: - Egal ob Server 2025 oder älter, die Einrichtung aktiviert nicht beide Dienste die zur Key-based authentication erforderlich sind, ebenso wenig passt die Firewall Regel so der Server Mitglied einer Domäne ist, # OpenSSH SSH Server als auf Startart automatisch setzen und starten Get-Service -Name sshd | Set-Service -StartupType Automatic Start-Service sshd # OpenSSH Authentication Agent als auf Startart automatisch setzen und starten Get-Service ssh-agent | Set-Service -StartupType Automatic Start-Service ssh-agent # Firewall so anpassen das nur dann Verbindungen möglich sind wenn die Firewall des Servers im Domänenprofil ist Set-NetFirewallRule -Name OpenSSH-Server-In-TCP -Enabled True -Profile Domain Damit ist vom Server alles fertig, alles andere sind Einstellungen (sshd_config unter %programdata%\ssh), Filesystem Rechte für die Benutzer und Keys. Was super funktioniert und genau mein Thema seitens der Rechte sauber abbildet: Es gibt die Möglichkeit mit zwei Zeilen die Rechte pro Benutzer sauber einzuschränken: Match User %domain%\%username% ChrootDirectory "%drive%\%path%" Das pro User eingetragen (und danach den Dienst gestartet für dazu das der User nicht mehr unter c:\users\%username% landet sondern in dem zuvor definierten Pfad und von da aus nur in Unterordner, nicht aber in die übergeordneten Laufwerke. Wichtig hierbei natürlich: Der Benutzer sollte auch Schreibrechte in dem Pfad haben wenn er Uploads durchführen soll.. Noch zwei ganz wichtige Anmerkungen: - die sshd_config ist Case Sensitiv, als Groß- und Kleinschreibung beachten, und Änderungen an ihr werden erst mit Neustart vom Dienst sshd übernommen - per Default können sich nur Administratoren verbinden, wenn es wie in meinem Fall bewusst mit normalen Benutzern laufen soll braucht man dazu mindestens eine Gruppe, diese wird beim Server 2025 zwar angelegt, nur bei einer deutschsprachigen Version leider eingedeutscht während die Konfiguration vom OpenSSH Server den originalen, englischen Namen verwendet. Ihr könnt hier sowohl die Gruppe umbenennen oder die Konfiguration anpassen, nur eins von beidem ist dann halt doch zwingend erforderlich.... Wie vermutlich jedem von uns ist mir bei diesem Thema eins sehr leidvoll aufgefallen: Viele Anleitungen geben nur Bruchstücke wieder, und die übersetzten Artikel sind immer wieder stark "verzerrt" und damit teilweise falsch, also wenn ihr sucht: Kämpft euch besser durch das englische Original, es schont die Nerven! Norbert

Habe jetzt noch mal genauer nachgesehen und das ganze auf einem Windows Server 2025 frisch aufgesetzt, meine anderen Tests waren glaub auch mal mit einem 2022er, aber das Notebook ist gerade auf dem Weg zur Reparatur, also kann ich nicht direkt nachsehen.... Es ist faszinierend wie unterschiedlich die Unterlagen zum Thema OpenSSH auf Windows Server sind, habe nach dem Tip von Google mir noch mal meine sshd_config angesehen die frisch erzeugt wurde und da gibt es wirklich die Zeile AllowGroups administrators "openssh users" was das Verhalten auf dieser VM erklärt. Bislang hatte ich aber auch nie den SSH Server über den Server Manager aktiviert sondern per Powershell..... Merke: Je nach OS Version und verwendetem Weg unterscheiden sich die Wege zur Einrichtung und die Rechte ungemein.... Aktiviere jetzt mal schnell die PubkeyAuthentication und teste weiter....

Ich merk schon - Dein Gedächtnis ist der Hammer... Werfe mein Testnetz an sowie ich daheim bin, Update folgt heute noch whoami /priv? Kannte ich auch noch nicht, gleich mal notieren Danke WOL konnte ich mein Lappi gerade mal anwerfen und kann folgendes berichten: 1.) Memberserver 2025 mit User Backup 2.) Domain Joined Windows 11 Pro Das deckt sich also mit Deiner Vermutung der unterschiedlichen Rechte auf Client und Server Ich dreh durch!!! Habe ganz strack gerade mal bei Tante Google nach folgendem gesucht: welche rechte braucht ein user um sich per ssh an einem windows server anzumelden Und damit bin ich gerade endlich weiter gekommen!!! Denn dann kam folgendes: Kaum habe ich die Gruppe der OpenSSH Users angelegt funktionierte die Anmeldung! Die Zugehörigkeit zur Gruppe der Remotedesktopbenutzer scheint aber nicht zu stimmen, ich habe den Backup User wieder aus der Gruppe geworfen und die Anmeldung funktioniert weiter Werde noch weiter testen, aber es geht endlich vorran! Norbert

Kennt von euch jemand eine Anleitung in der das Thema Rechte von OpenSSH unter Windows erklärt wird? Mir ist bislang noch nichts erleuchtendes untergekommen :-(

Dann verstehe ich Dich nicht, ist ein Domänen Benutzer in einem nackten Test ohne jeglichen Sonderrechte

Hallo Jan, ich verstehe vollkommen was Du meinst, ich kämpfe halt immer wieder mit den dauerklammen Schulfinanzen, das ganze dann noch gepaart mit dem Technikerspieltrieb (das muss doch auch mit Bordmitteln gehen - oder nicht?), aber berechtigt ist die Frage. Hätte eigentlich gedacht mit OpenSSL als Basis eigentlich gefühlt den Standard schlecht hin nutzen zu können? Norbert

Er ist aktuell weder auf Client noch Server Admin, wirklich stumpfer User :-)

Ich habe jetzt mal noch weiter gegraben: - eine Verbindung mit einem Adminkonto über ssh -i id_ecdsa -l user@domainfqdn host funktioniert - eine Verbindung mit einem nicht Adminkonto (Backup) über ssh -i id_ecdsa -l backup@domainfqdn host funktioniert nicht Fehlermeldung: Permission denied (publickey,keyboard-interactive) Fehlt dem Benutzer Backup das Recht zur Interaktiven Anmeldung? Kann das die Ursache sein? Norbert

Hallo Freunde der Windows Welt, kennt sich von euch jemand mit dem OpenSSH in Windows aus? Ich kämpfe seit einer Weile immer wieder mal mit der Möglichkeit einen Windows Server als SFTP Server für Backups von Geräten zu nutzen die nur mit SFTP & Keyfile Anmeldung übertragen können. Ich habe mittlerweile einiges am Laufen, aber halt nicht alles :-( Es gibt ja von Microsoft eine recht ausführliche Anleitung mit deren Hilfe ich es sowohl auf Windows Clients als auch Servern schon versucht habe ans Laufen zu bekommen. Tut auch grundlegend, nur die Anmeldung als normaler User will bei mir nur mit Admin Accounts, nicht aber mit normalen Usern. Wenn ich es richtig verstehe sollte eigentlich bei Clients die sich per SSH auf einen entfernten Host verbinden - wenn vorhanden - der lokale Key aus C:\Users\%username%\.ssh genommen werden wenn auf dem Server der Key passend hinterlegt wurde (als authorized_keys). Mache ich das mit einem Win11 Client als SSH Server funktioniert die Anmeldung als User und ich werde nicht mehr nach dem Passwort gefragt, beim Server (momentan Teste ich gegen Server 2025) aber schon :-( Habe die sshd_config schon zwischen Client und Server verglichen, beide haben die Option PubkeyAuthentication yes aktiviert (fehlt ja sonst), aber dennoch verhalten sich Windows Server und Client bei mir unterschiedlich und ich weiß nicht wieso :-( Grüße aus BaWü Norbert

Habe mittlerweile DFS komplett gekillt, ne Stunde gewartet und danach zwei DFS angelegt, Computer haben auf keins von beiden Zugriff :-(

Sodele, nach ein paar Tagen außer Gefecht sitze ich jetzt endlich wieder an unseren Sorgenkindern... Test 1: Client macht einen dir auf \\dc-01\msi$ und sieht alles Test 2: Client macht einen dir auf \\dc-02\msi$ und sieht alles Test 3: macht einen dir auf \\domänenfqdn\dfs\msi und sieht nichts Test 4: macht einen dir auf \\domänenfqdn\dfs und sieht nichts Test 5: User macht einen dir auf \\domänenfqdn\dfs\msi und sieht alles Test 6: User macht einen dir auf \\domänenfqdn\dfs und sieht alles Sagt mir: Die Computer haben keinen Zugriff auf den DNS Share, also habe ich das so ausgebaut das auch die beiden DFS Shares auf den DCs per dir aufgelistet werden, aber auch das ist leer :-( Genau das verstehe ich aber nicht, denn die Ordner für den DFS Share auf beiden DCs sind genauso freigegeben wie auch in meinem Testnetz zum Gegentest: Jeder mit Lesen... Mir fehlt gerade der nächste Schritt wie ich das lösen könnte :-( Norbert

Hey Nobbyaushb,, der FQDN ist erreichbar, ich konnte es ja schon auf den Zugriff der Computerkonten runterbrechen. das mit dem anderen Ordner im DFS habe ich letzte Nacht ja schon geschrieben, genau die Idee kam mir letzte Nacht auch schon in den Sinn. Update folgt. Norbert

Jupp, so ist es gebaut und das tut nicht. Habe mir gerade mal überlegt einen weiteren Ordner im DFS anzulegen um zu sehen ob es dann funktioniert. Mache ich morgen im Büro und gebe Rückmeldung Norbert

Guten Morgen liebe Leidensgenossen, wir haben heute früh ein uns so noch nie untergekommenes Erlebnis mit DFS das wir uns nicht erklären können: In unserem Netz dessen AD es seit 2006 gibt nutzen wir die Möglichkeit zur Softwareverteilung per GPO und DFS, dazu haben beide DCs einen Share DFS in dem dann der Ordner für die MSI Packages liegt: \\dc-01\dfs\msi \\dc-02\dfs\msi Anders als noch bis letzten Sommer (genauer konnten wir es noch nicht eingrenzen) haben aber neuerdings die Clients keinen Zugriff mehr auf die Freigaben über DFS, nur über den direkten UNC Pfad: \\dc-01\msi \\dc-02\msi Nachdem uns die Fehlermeldungen im Eventlog der Clients nach und nach gezeigt haben das es wohl ein Problem mit dem Quellpfad der MSI gibt wissen wir es seit letzter Nacht, wir haben nämlich zum Test mal eine GPO angelegt die auf das Computerkonto wirkt und einen dir \\domain\dfs\msi komplett leer anzeigt, ein dir \\dc-01\msi und dir \\dc-02\msi hingegen Inhalte bringt.... Hat jemand eine schlaue Idee woran das liegen könnte? Grüße vom Glatteis Norbert

Das sind die Details vom Spooler.. Habe gerade noch mal nachgesehen bevor ich was falsches Safe - die Treiber sind freigegeben: HP UPD 7.3.0, Xerox GPD PS 1035.2.0 und dann noch Develop 3.1.12.0 - mehr haben wir nicht Zu den angezeigten Details habe ich noch nicht wirklich was passendes gefunden :-( Norbert

Hallo Freunde der Windows Welt, ich verzweifel gerade bei uns an der Schule an der Windows 11 Umstellung... Wir haben ~200 Notebooks unterschiedlicher Modell (alles HP) die bislang problemlos auf Windows 10 liefen. Vereinzelte Geräte funktionieren bereits seit rund zwei Jahren mit Windows 11, der Rest soll jetzt über die Sommerferien auf Windows 11 aktualisiert werden. Leider haben die meisten Maschinen nach dem Update das Problem, das sie sich nicht mehr mit dem Radius gesicherten WLAN verbinden können. Da neu installierte Maschinen problemlos laufen kann ich die GPOs und auch den NPS ausschließen, nach langer Suche ist uns folgendes aufgefallen: Im bekannten WLAN gibt es zwar das Profil - aber ohne SSID??? Auch löschen des Ordners C:\Windows\wlansvc\Policies und damit der übernommenen Richtlinie hilft nicht weiter.... Was auch für die Diagnose spricht das der Client das Sorgenkind sein muss: Am NPS kommen keinerlei anfragen vom Client an.... Ratlose Grüße Norbert

Da hatte ich eigentlich nachgesehen und nichts entdeckt, aber da es sicher nicht lange auf sich warten lässt checke ich das die Woche noch einmal sowie der Fehler kommt.... Update folgt Norbert

Also außer der der Spooler mir unverständlicher Weise Verbindungen zu einem unseren Terminalserver hat (auf dem bis zu meiner Anmeldung niemand angemeldet war) habe ich noch keine Erleuchtung finden können :-(

Heute Nacht war es mal wieder so weit: 100% CPU Last.... Also war in diesem die Treiber Isolation leider noch nicht die Lösung, also weiter suchen, denn von alten, nicht mehr benötigten Treibern habe ich den Server bereits befreit und jetzt im Schuljahr (hier an BaWü haben wir noch bis Ende des Monats Schule) darf ich die Treiber nicht aktualisieren... Gruß Norbert