Edvvde

Sowohl als auch. Aber inwiefern soll das Full-Backup für dieses Verhalten verantwortlich sein? Wobei ich mir das für den Health-Check auch nicht erklären könnte, außer das es hier Auslastung aufs NIC-Team gibt ... Es laufen auch "nur" Backups für die VMs, nicht für den Hypervisor selbst. Jap, hier wurden alle entsprechenden Exclusions gesetzt, die Microsoft für einen Hyper-V Host vorgibt. Berechtigte Kritik! Jedoch ist in diesem Fall leider keine weitere Lizenz für eine weitere VM vorhanden, daher läuft Veeam direkt auf dem Hypervisor. Habe ich auch schon dran gedacht, ich finde jedoch nichts zum Treiber im Ereignisprotokoll und auch nicht in den Geräten selbst. Trotzdem werde ich mal Chipsatz und LAN Treiber auf den Tisch holen. Es gibt außerdem noch VLANs für Drucker und VOIP. Berührt den Server aber eigentlich nicht.

Hallo zusammen, man könnte scherzhaft sagen, auch ein Hyper-V hat mal Wochenende leider macht uns das Folgende jedoch seit einiger Zeit diverse Probleme. Immer zum Wochenende hin (würde es auf Freitag / Samstag festnageln) läuft ein Hyper-V unter Server 2019 instabil. Ich merke dies an verschiedenen Stellen: - im Monitoring (NIC-Team fällt aus, bzw. Mitglied) - das Backup der VM mit Veeam scheitert aufgrund verschiedener Fehler - ich kann alle VM in Hyper-V nicht mehr Herunterfahren, erhalte einen Fehler (VM bleibt im Status "Beenden") - im Hyper-V Manager bekomme ich zu laufenden VM keine Info mehr unter z.B. "Netzwerakdapter" angezeigt (die VM läuft dann aber noch und man kann darauf Arbeiten) - ein Neustart des Hyper-V Dienstes schlägt fehl - ein Neustart des Hosts schlägt fehl, er bleib im Status (Hyper-V Dienst wird beendet) - einzig ein Hardreset des Hypver-V host via RMM hilft und erstmal läuft dann wieder alles normal, bis zum Wochenende ... Es ist auffällig, dass die Probleme zum Wochenende hin auftreten. Eigentlich ist hier nichts anders, die Endpointsoftware (SOPHOS) läuft dauerhaft und macht täglich Scans. Backups der VM finden ebenfalls täglich statt, sowohl auf NAS als auf RDX. Den einzigen Unterschied, den ich festmachen konnte: In der Nacht zum Samstag läuft ein Health-Check des Backups mit Veeam, welches auf der NAS lagert (dies haben wir nun mal zum Test deaktiviert). Resultutat wird sich vermutlich erst in einer Woche zeigen. Aber selbst wenn, hat jemand eine Idee, was hier Sache sein könnte? Hoffen wir, dass es beim Wochenende bleibt und der Hyper-V nicht auch noch Weihnachtsurlaub beantragt Schönes WE

Nabend zusammen, habe hier einen Hyper-V Server 2019 auf dem ich DDA für eine VM umsetzen wollte. Der Server hat ein Supermicro H11Dsi-NT Board und 2 EPYC Prozessoren verbaut. Als bisherige PCI Geräte gibt es einen RAID-Controller sowie eine 2x10Gbits Netzwerkkarte. Hinzugekommen ist nun eine RTX 4000 ADA SFF welche via DDA durchgereicht werden soll. SR-IOV ist im BIOS Enabled. Das SurveyDDA Skript meldet für die RTX folgendes: Traffic from this device may be redirected to other devices in the system. Not assignable. Kann damit vielleicht jemand was anfangen?

Der Host wurde letztes Jahr direkt unter 2022 aufgesetzt, also kein Upgrade oder sonst was ...

Ist ein Hyper-V Host, Server 2022

Es wurden in diesem Fall keine Patches installiert ... das es hier mal Probleme gab mit Updates konnte ich durch etwas Recherche auch in Erfahrung bringen. Das REFS Volume war nach einem Neustart einfach nicht mehr zugreifbar (als RAW Basisdatenpartition angezeigt). Im Anhang Screenshots aus dem Eventlog, in 12 Jahren habe ich das so noch nicht erlebt ... Lösung: Habe zwar - trotz eingelegter Nachtschicht - keinen Weg gefunden, dieses Volume ohne Formatierung wieder nutzen zu können. Jedoch konnte ich alle für uns wichtigen Daten aus diesem RAW Volume wiederherstellen. Dafür kam ein Bordmittel zum Einsatz, welches scheinbar nicht wirklich oft genutzt bzw. nur sehr sehr selten beschrieben wird: REFSUTIL Durch den "Vollständigen automatischen Modus: refsutil salvage -FA <source volume> <working directory> <target directory>" konnten alle Dateien (in diesem Fall *.vhdx) aus dem RAW Volume auf ein Netzlaufwerk wiederhergestellt werden. Es hätte hier natürlich auch ein Backup gegeben, welches jedoch den Verlust von ca. 24h an Daten zur Folge gehabt hätte.

Hallo zusammen, wir haben auf einem Windows Server 2022 das Problem, dass die Datenpartition (Volume D) als RAW angezeigt wird (nach Neustart) und ein Zugriff somit nicht mehr möglich ist. Das ursprüngliche Dateisystem war REFS. Sowohl Systemplatte C also auch Datenpartition D sind via RAID-Controller auf einem RAID10. Hat hier vielleicht jemand eine Idee? Danke euch!

Auch interessant: - Copy & Paste auf leeren Ordner (keine Reaktion, es passiert also nichts), normalerweise sollte hier ein weiterer leerer Ordner als Kopie angelegt werden - Ausschneiden und einfügen auf einen leeren Ordner (ebenfalls keine Reaktion) Legt man nun ein leeres Textfile in diesem Ordner an, wird bei Copy & Paste dieses Textfile im Ordner als Kopie angelegt, nicht aber der Ordner selbst. Mache ich ein Ausschneiden und Einfügen auf den !Ordner!, meldet er mir, dass die QuellDATEI und ZielDATEI identisch seien. Auf anderen Maschinen wird hier gemeldet "Quell- und ZielVERZEICHNIS" sind identisch ...

Hallo Zusammen, aktuell kann ich mir noch keinen richtigen Reim darauf machen, vielleicht sehe ich auch den Wald vor lauter Bäumen nicht aber wir haben aktuell auf einem Netzlaufwerk (Windows Fileserver VM) das Verhalten, dass wenn ich einen Ordner kopiere und diesen im selben Verzeichnis einfüge, keine Kopie dieses Ordners angelegt wird, sondern eine Kopie dessen Unterordner und Dateien im zuvor zum kopieren ausgewählten Ordner angelegt wird. Dieses Verhalten haben wir jedoch nicht bei allen Ordnern sondern nur bei "älteren". Nicht bei Ordnern die neu angelegt wurden (zum Test z.B.). Außerdem tritt das Verhalten nicht von allen Clients auf. Es ist jedoch kein Muster zu erkennen ... Weiß jemand was dieses Verhalten hervorbringt? Danke & Gruß

Du sagst es, es schafft neue Probleme. Die Softwarequalität ist einfach unter aller Sau. Wir zögern Updates schon bis aufs letzte raus und wenn wir dann quasi wegen irgend welchen neuen CVEs gewzungen sind zu handeln, dann kann man eigentlich schon für die kommenden Tage das Feldbett am Rack aufbauen.

Der Microsoftsupport lässt weiterhin auf sich warten ... scheinbar Fachkräftemangel im 1st level ... // Kurzes Update: Die Ursache ist ein Softwarefehler in der aktuellen Version von FSLogix 2210 (2.9.8361.52326). Ein Downgrade auf Version FSLogix 2201 hotfix 2 (2.9.8228.50276) löst das Problem in Luft auf. Zwei Schlaflose Nächte am Produktivsystem weil wieder irgend ein Mist gepulished wurde ... I love it ...

Moin zusammen, hier mal wieder eine Odyssee, wir befinden uns noch mitten drin. Kurz zur Erklärung: - Windows Server 2019, RDS (FSLogix) -- Updatestand 01/23, FSLogix 2210 (2.9.8361.52326), Office (Version 2212 Build 16.0.15928.20196) 64 Bit --- getrennte Container für Userprofile als auch Office ---- M365 E3 bei allen Usern, MFA aktiviert Seit Update auf 12/22 (weiterhin vorhanden aktuell auch bei 01/23) verlangen die Office 365 Apps nach An-/Abmeldung vom Server ständig einen neuen Login (auch mit Abfrage MFA). Ist man angemeldet und die RDS-Sitzung wird nicht abgemeldet, kann man ungestört arbeiten, sobald die RDS Sitzung aber ausgeloggt wird, muss man sich wieder neu Anmelden. Problem betrifft nur RDS, lokale Clients nicht betroffen. Was schon versucht wurde: - DISM Online / als auch Offline-Image erfolgreich - SFC Reparatur erfolgreich, chkdsk erfolgreich - Credentials im Credentialsmanager gelöscht - Online Reparatur M365 - Reparaturinstallation FSLogix - Registry Identity Ordner innerhalb des Current User gelöscht (führte nur größeren Loginproblem) - komplett neuer User sowohl in AD also auch AzureAD (mit und ohne MFA) - GPO FSLogix Aktivierung Office in Office Container ein-/ausgeschalten - Microsoft Support und Wiederherstellungs-Assistenten (SetupProd_RoiScanFull, SetupProd_Act, SetupProd_OfficeSharedComputer, SetupProd_OfficeSignIn) Es ist zum Mäuse melken. Ticket bei Microsoft läuft, Antwortzeit aktuell aber eine mittelschwere Katastrophe ... Vielleicht noch jemand eine Idee? Ansonsten bleibt nur Recovery auf Stand vor Update, aber irgendwann müssen die Updates ja gemacht werden ... LG

Kurzes Update: Es hat den Anschein, dass das Problem mit OneDrive Preview 22.166.0808.0002 nicht mehr existiert. Zumindest tritt der Fehler nun seit ca. einer Woche nach Installation nicht mehr auf und lässt sich auch nicht mehr provozieren. Man darf gespannt sein, ob dies auch für das nächste offizielle Release gilt.

In der Microsoft Communiy existiert nun seit dem 17.08. ein Eintrag eines französischen Users welcher den selben Fehler Unter Win 10 21H2 beschreibt. Ich habe mich dem Thema mal angeschlossen sowie ein Ticket beim M365 Support eröffnet. https://answers.microsoft.com/en-us/windows/forum/all/onedrive-constantly-disappears-on-file-explorer/2faa1d87-5bb8-4b3e-b48f-a31eb215bf93?rtAction=1660817114279 //Update: In dem Thread häufen sich mittlerweile die Meldungen von Usern mit der selben Problematik. Man kann den Fehler auch reproduzieren in dem z.B. im Browser eine Datei hochgeladen wird oder aus einer anderen OneDrive (Freigabe). Sobald der Client lokal anfägt zu syncen, verschwindet das OneDrive Symbol als der Sidebar im Explorer. Ist man in diesem Moment über dieses Symbol aus der Sidebar in einem Ordner innerhalb OneDrive am arbeiten erscheint zusätzlich die Fehlermeldung "explorer.exe ..." Es scheint sich also um ein Softwareproblem zu handeln, bis jetzt vermutlich aufgetreten nach KB5016616 und KB5012170 ...

Kleines Update: Der Fehler besteht leider immernoch. Inzwischen ist auch klar, dass es nicht nur ein Profil betrifft, sondern sich sogar provozieren lässt indem man den OneDrive Ordner über das Cloudsymbol links (unter Schnellzugriff) aufruft und dort dann einwenig "wild umherklickt". Was auch noch nachvollzogen werden konnte ist, dass statt des Pfads also z.B. C:\Benutzer\OneDrive\ im Explorer dann eine ID steht z.B. : Diese ID konnte ich in der Registry finden unter HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace Der Eintrag dort verschwindet in dem Moment in dem der Fehler auftritt aus der Registry. Ich vermute es fehlt dann schlicht und einfach die Verknüpfung in diesem Moment. Das würde auch erklären, wieso das Problem nur auftrtitt, wenn man mit dem OneDrive Ordner über die die Schnellzugriff-Liste links arbeitet, nicht wenn man z.B. via Doppelklick auf das OneDrive Symbol in der Taskleiste neben der Uhrzeit geht ... Was bereits versucht wurde sind die klasischen Ansätze DISM /restorehealth und sfc /scannow welche auch einwandfrei durchliefen. Der Server hat nun das August Update bekommen, FS Logix ist ebenfalls auf dem aktuellsten Stand FSLogix 2201 hotfix 2 (2.9.8228.50276) und OneDrive auf 22.151.0717.0001 (64-Bit) installiert als machine-based. OneDrive wurde auch mal zum Test deinstalliert sowie die das online-repair von Office ausgeführt, ohne Erfolg.