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.

Um die ganze Geschichte mit M365 (Exchange Cache) und OneDrive lauffähig zu haben, ist hier FSLogix im Einsatz. Es handelt sich also um Profilcontainer mit seperaten Containern für alle Daten was M365 angeht. Ich hatte hier bereits beide Container mal gelöscht und frisch aufsetzen lassen, was aber nicht zur Problemlösung beigetragen hat, leider ...

Hallo zusammen, ist jemandem vielleicht schon mal dieser Fehler begegnet? "Explorer.EXE: Der Datei ist keine App zum Ausführen dieser Aktion zugeordnet. Installieren Sie eine App, oder erstellen SIe auf der Einstellungsseite für Standard-Apps eine Zuordnung, wenn bereits eine App installiert." Aufgetreten hier auf einem Windows Server 2019 welcher als Terminalserver fungiert, jedoch bisher nur bei einem User. Habe mehrere Communityeinträge dazu gefunden, aber meist eher unspezifisch und aufgetreten auf Clients. Wobei es hier auch mutmaßlich immer in Verbindung mit dem OneDrive Sync Ordner auftritt. Interessanterweise verschwindet die OneDrive Wolke links im Schnellzugriff, sobald der Fehler auftritt, ist ähnlich wie bei diesem User hier: https://answers.microsoft.com/en-us/windows/forum/all/error-explorerexe-this-file-does-not-have-an-app/6eefb639-08fc-42e3-ab1d-d3b5343d4105 Erst nach einer sauben Ab-/Anmeldung ist alles wieder für mehrere Minuten manchmal Stunden normal ...

Hallo zusammen, wenn es nach Microsoft geht, ist der Terminalserver ja eigentlich ein weiteres Mal (war ja schon bei 2019 angekündigt, wurde aber ja zurückgerudert) als Totgeburt auf den Markt geworfen. Office 365 wird nicht unzerstützt laut Microsoft: https://docs.microsoft.com/de-de/deployoffice/endofsupport/windows-server-support Fakt ist aber auch, es läuft auf einem Windows Terminalserver 2022 mit entsprechender E3 Lizenz einwandfrei, als wäre nichts. Hat hier vielleicht jemand in die Glaskugel geschaut und kann sagen, ob Microsoft nur den Support meint oder es ggf. eines Tages einfach einen Lizenzfehler schmeißen wird? Und Server 2019 ist ja auch so eine Sache: "Wird bis Oktober 2025 unterstützt." Kann mir nur vorstellen, dass auch der Support hiermit gemeint ist. Aber einfach durch Lizensierung abschalten ... kann ich mir eigentlich nicht vorstellen da 2019 selbst ja bis Ende 20er Jahr laufen soll ... LG

Wollte hier noch kurz auflösen: Anscheinend hatte sich ein Windows Service Update festgefahren. Habe mit einem Windows Image in CMD gebootet und mit DISM mir die installierten Packages anzeigen lassen DISM /Image:C:\ /Get-Packages /format:table > C:\updates.txt Notepad C:\updates.txt Dort dann das austehende bzw. fehlerhaft installiert Package ausfinding gemacht und mit DISM /Image:C:\ /Remove-Package /PackageName:hier_der_packagename Das fehlerhafte Package entfernt. Die VM ließ sich danach wieder booten und das Update konnte wiederholt werden. Falls jemand mal in ähnliche Probleme läuft ;) Gruß

Danke für deine Antwort. An den Druckerspooler glaube ich eigentlich nicht. Alle anderen VMs auf dem Host und sogar der Host selbst haben das selbe Update erhalten und machen keine Probleme, nicht mal die VM über die von Clients lokale Drucker angesteuert werden ...

Hallo zusammen, ich habe hier eine VM (Server 2019 Standard, keine Rolle, Server für DMS & ERP inkl. Datenbank) die mich noch in den Wahnsinn treibt. Aufgefallen ist das Problem gestern Abend, Windows Updates wurden eingespielt (KB5005568). Dann fing das Theater an, die VM wollte nicht mehr booten, wirft dreimal einen Bluescreen (Fehlercode 0xc000021a) und bootet dann in den Recovery. Habe aus Backup vom Freitag Abend die komplette VM zurückgespielt, läuft einwandfrei. Datenbanken laufen alles supi. Also Update erneut eingespielt, gleiches Problem. Also wieder Backup zurückgespielt. Dann sfc /scannow (kann keine Probleme feststellen). Beim booten chkdsk /f /r findet auch nichts. DISM /scanhealth meldet das repariert werden kann. DISM /recoverhealth bricht bei um die 97% ab und meint dann 0x800f081f source not found. Dann ISO von Server 2019 Eval 1809 besorgt und DISM befehl mit source abgesetzt (sowohl Online dism /online /cleanup-image /restorehealth /source:WIM:E:\sources\install.wim:2 als auch offline im Recovery Mode dism /image:c:\ /cleanup-image /restorehealth /source:wim:E:\sources\install.wim:2, Fehler 0x800f081f source not found bleibt bestehen. Also VM wieder zurückgespielt aus Backup. Update manuell versucht sowohl KB5005568 als auch die Preview nach erneutem rückspielen KB5005568, landen wir wieder am Anfang bei Fehlercode 0xc000021a. Also wieder rückgespielt, als nächstes SFCFix versucht, DISM schlägt weiterhin fehl. .NET Framework 4.0 entfernt, Update versucht, wieder Bluescreen. Hat hier vielleicht noch jemand eine Idee, außer die komplette VM neu aufzusetzen? ...

Die Clients über die Systemeigenschaften aus der Domäne entfernen bzw. statt Domäne wieder in eine Workgroup packen. Netzwerkfreigaben sind (bis auf die zugwiesenen Berechtigungen aus der AD) unabhängig davon ob in einer Domäne oder nicht. Mir erschließt sich aber nicht weshalb du die Domäne auflösen möchtest ... dann macht der "Server" meiner Meinung nach wenig Sinn, dann hätte es auch ne NAS getan wenn es nur um Dateifreigaben geht.

Um das Thema abzuschließen, es gibt keine (bessere) Lösung (für die o.g. Konstellation) als FSLogix, damit läuft alles mehr als einwandfrei und bietet noch zahlreiche weitere Schmankerl. Gruß

Glaub mir Norbert, der Fehler unterläuft nicht nochmal ;) Aber was passiert in der Karnevalszeit nicht alles, das eigentlich nicht hätte passieren sollen

Nils, keine Frage hätte nicht passieren sollen. Es gibt aber noch einiges an Konfiguration drum herum, welche deutlich mehr Zeitaufwand bedeutet hätte. Wäre es ein blanker DC, stimme ich dir zu 110% zu. Allein den Text hier fürs Forum wäre es zeitlich nicht wert gewesen. Ist aber vielleicht interessant für jemanden, der mal in einer ähnlichen Situation ist. Es scheint doch möglich zu sein. Vielleicht besteht ja überhaupt kein technischer Hintergrund sondern es ist vielleicht nur dem Umstand geschuldet, dass die Evaluation nicht für Produktivumgebung zugelassen ist. Oder es ist mittlerweile supportet nur (noch) nicht offiziell kommuniziert, wer weiß ...