Homeserver Forum

Läuft QSM denn? Wenn nicht starten und schau dann mal, ob sich bzgl. DEUtil etwas verändert ... neuer File alle Stunde und nicht im Minutentakt

Generell kannst du QSM wieder auf automatisch stellen ...

Ich bin mir nicht sicher, warum die beiden Included...-Einträge bei dir wieder zerstört sind, in meiner Umgebung hat das funktioniert. Scheinbar gibt es irgendwo noch ein Problem

Läuft QSM denn?

Ja lief trotzdem...

Ich bin mir nicht sicher, warum die beiden Included...-Einträge bei dir wieder zerstört sind, in meiner Umgebung hat das funktioniert. Scheinbar gibt es irgendwo noch ein Problem

Was ist denn mit den letzten beiden Fehlern, können die einen Einfluss dararauf haben?
--> 8E92313D-E075-4C18-B0A4-D2A70C0116D0 ohne passenden MountPoint
--> Signatur ungleich SystemName
Aber die beziehen sich auf die DATA Platte?

Die GUID habe ich schon mehrfach verglichen, da scheint nur in WHSDisks ein ToUpper beim Vergleich zu fehlen ... du könntest ja testweise entweder bei einen die Klein- durc h Großbuchstaben ersetzen oder umgekehrt
Der Signaturfehler hatte bei mir keine Auswirkung, ist auch nicht einfach zu fixen

Die Bezeichnung DATA-Platte ist nicht korrekt, DATA ist der Namen der 2. Partition der Bootplatte und ALLER zusätzlichen Platten des Storagepools, Microsoft bezeichnet sie als "Primary Voilume" und "DE Secondary Volume".

Sagt dir der Begriff Tombstones etwas? Tombstones sind die Einträge aller Verzeichnisse und Dateien in den Shares und sind keine echte Dateien sondern nur Zeiger auf den realen Standort (bei Duplikation: die realen Standorte) der Dateien. Diese Info durch die GUIDs der jeweiligen Platte im "Header" des Tombstones eingetragen. Wenn diese GUIDs durch das ursprüngliche Problem auch verändert worden sind, dann haben wir ein echtes Problem. Und ob das passiert ist, ist schwer zu prüfen. Ich weiß zwar wie das geht, aber im Monet nicht wie ich das erklären soll

Du könntest noch einmal folgendes machen:
den heutigen QSM-Log löschen, dafür musst du vorher den QSM Dienst stoppen (verbundene Dienste werden dabei auch gestopped)
Booten
5 Minuten warten
den neu erstellten QSM-Log posten ... der ist schwer lesbar, aber vielleicht steht da ein Hinweis drin

Die GUID habe ich schon mehrfach verglichen, da scheint nur in WHSDisks ein ToUpper beim Vergleich zu fehlen ... du könntest ja testweise entweder bei einen die Klein- durc h Großbuchstaben ersetzen oder umgekehrt
Der Signaturfehler hatte bei mir keine Auswirkung, ist auch nicht einfach zu fixen

Das mit der Groß- und Kleinschreibung habe ich schon versucht, nachdem ich in den logs Klein- und in deinen Anweisungen Großbuchstaben gesehen habe, Verzweiflungstat, mache das dann nochmal.

Die Bezeichnung DATA-Platte ist nicht korrekt, DATA ist der Namen der 2. Partition der Bootplatte und ALLER zusätzlichen Platten des Storagepools, Microsoft bezeichnet sie als "Primary Voilume" und "DE Secondary Volume".

Verstehe ich, deswegen schreibe ich von der SYS-Platte oder der DATA-Platte und von C: und D:, ich dachte, das wäre einfacher...

Sagt dir der Begriff Tombstones etwas? Tombstones sind die Einträge aller Verzeichnisse und Dateien in den Shares und sind keine echte Dateien sondern nur Zeiger auf den realen Standort (bei Duplikation: die realen Standorte) der Dateien. Diese Info durch die GUIDs der jeweiligen Platte im "Header" des Tombstones eingetragen. Wenn diese GUIDs durch das ursprüngliche Problem auch verändert worden sind, dann haben wir ein echtes Problem.

Habe ich im Forum drüber gelesen, verstanden und auch selbst bemerkt, wenn ich Dateien im Share-Verzeichnis anklicke, lassen sie sich nicht öffnen...

Und ob das passiert ist, ist schwer zu prüfen. Ich weiß zwar wie das geht, aber im Monet nicht wie ich das erklären soll

Ich muss nicht alles verstehen

Du könntest noch einmal folgendes machen:

Da bin ich dein Mann!

Also ... wenn ich bei meinem Testsystem den SystemName und DevicePath des Volumes, das den Namen DATA und den LW-Buchstaben D: hat, verändere, dann ist nach dem nächsten Boot IncludedDirectories und IncludeDirectoriesDuplication zerstört und mit einer oder mehrfacher Angabe der Form x:yy überschrieben.

Ich habe mit dem PROCMON die Bootphase gelogged und dabei gefunden, dass es, wie vermutet, wirklich der QSM macht ... but why?
Der Unterschied bei mir ist, dass wenn ich die Einsrtellungen wieder richtig mache, dann ist nach dem nächsten Boot auch alles wieder OK

Ich werde mir jetzt dann mal in Ruhe dein QSM-Logging ansehen ... ist ja bisher (heute?) nicht ganz so warm im Dachgeschoss

Hmmm ... nach der ersten Analyse des QSM-Log scheint es wohl doch an der Disk-Signatur zu liegen ... die Fehlermeldungen sind zwar nicht eindeutig, aber da sind welche, dass er die Verzeichnisse für die Shares nicht findet

Leider kann die Version von DISKPART, die auf dem Server 2003 ausgeliefert wird die Signatur einer Platte nicht ändern jetzt könnte man entweder die Einträge für die Platte in der Registry so ändern, dass die veränderte Signatur akzeptiert wird, da kann ich aber das Risiko überhaupt nicht einschätzen, oder du könntest die Platte an einen anderen Rechner hängen, wo DISPART das UNIQUEID Kommando kennt ...

Aber Vorsicht mit DISKPART, damit habe ich mir schon einige Platten zerschossen

list Disk ... hier sieht man welche disk (nummer) die richtige ist -> n
select disk n
detail disk ... noch mal prüfen, ob es wirklich die richtige Platte ist ... muss 2 Partitionen (SYS und DATA) haben
uniqueid disk ... hier müsste dann AF55CA01 anzeigt werden
uniqueid disk ID=BBF5E899
uniqueid disk ... jetzt müsste hier der neue Wert angezeigt werden

Dann Platte wieder in den WHS, booten und hoffen

Okay, versucht: Kleinschreibung der disk, IncludedDirectories und IncludedDirectoriesDuplication geändert. Ein Fehler ist weg, die ID.

Ich habe ja keine Ahnung (...und schon mal gefragt), aber:
Hat die falsche InstanceID bei der Systemplatte Auswirkungen?

Was mir wieder einfällt, die DATA-Platte hatte ich auf Garantie ausgetauscht bekommen, deswegen haben die Platten verschiedene Firmware.

Als Inhalt der InstanceId habe ich schon alles mögliche gesehen ... ich kann (fast) ausschließen, dass es da einen Zusammenhang gibt ..

Was mich allerdings wundert ist der Inhalt das QSM-Log ... da scheint am Anfang etwas zu fehlen ? Hast du das genauso gemacht wie beim letzten mal?

UND: jetzt kommt wieder die MountPointGUID / DevicePath Fehlermeldung ... und genau diese Abweichung führt bei mir reproduzierbar ja zur Zerstörung der IncludedDirectories

Hast du das genauso gemacht wie beim letzten mal?

QSM steht auf automatisch, meinst du ausschalten, auf manuell setzten, reboot und dann QSM-logs?

Ne, QSM stoppen, Logfile löschen, booten ...

Würde es etwas nützen, die Konsole zurückzusetzen?