Documents-Ordner [gelöst]

von **nohype** » 22.12.2024, 04:13

PS. Ich würde gern auch den Titel mit "gelöst" kennzeichnen.

von **nohype** » 22.12.2024, 04:09

Ich habe zwischenzeitlich nicht mein Ziel aus dem Auge verloren.
Ausgangspunkt war ja die bei verschiedenen Programmen auftretende Fehlermeldung, dass bei irgendwelchen Speicheraktionen mit verschiednen Programmen ein tatsächlich nicht vorhandener Netzwerkpfad zum Documents-Ordner nicht gefunden wird.
Bisher hatte ich nach dem irritierenden falschen Computernamen nur in der Registrierung und in den Windows-Systemordnern gesucht.
Da bei nun bei einer erneuten Installation der Rodeprogramme der ursprüngliche Fehler wieder auftauchte, habe ich die Suche nach dem String DESKTOP-F02764I auf das gesamte Laufwerk C: ausgedehnt. Das dauerte natürliche eine gewisse Zeit, hatte aber Erfolg:
der Fehler lag in den in Windows 10 standardmäßig versteckten Bibliotheken.
In allen Bibliotheken war nämlich der falsche Netzwerkpfad vorhanden, insbesondere enthielt die Bibliothek: Dokumente neben dem Ordner V:\Dokuments auch den parasitären Ordner DESKTOP-F02764I\Documents. Ich weiß nicht, wie der da hin gekommen ist.
Meine frische Windows 10-Vergleichsinstallation enthält in den Bibliotheken keine Netzwerkpfade.
Ergo: das ursprüngliche Problem ist nun gelöst.

von **nohype** » 02.12.2024, 23:38

nohype hat geschrieben: 02.12.2024, 03:08 Meine Diagnose ergibt hier, dass vier Textdateien potentiell für den Fehler verantwortlich sind: sie enthalten alle den fraglichen, früheren Computernamen DESKTOP-F02764I und z.T. noch ältere, früher benutzte:
Code: Alles auswählen
C:\Windows\debug\NetSetup.LOG
C:\Windows\System32\wmi.txt
C:\Windows\System32\drivers\etc\hosts.ics
C:\Windows\System32\wbem\WMIMigration.log
Da ich die Funktion dieser Dateien aber nicht kenne, habe ich da noch nichts verändert, der Fehler also weiter besteht, solange ich da nichts verändere.
Naheliegend wäre es, alle vorkommenden auch noch älteren, parasitären Computernamen durch den aktuellen Computernamen manuell zu ersetzen. Dass das zu einer gültigen Konfiguration führen würde, erscheint mir aber fraglich.

Ich bin nun einen anderen Weg gegangen:
Ich habe die o. g. vier Dateien mit den entsprechenden in einer frischen W10-Installation verglichen, die ich immer zum Vergleich auf einer anderen SSD bereithalte.
Da dort von den vier Dateien überhaupt nur zwei existieren, habe ich probeweise gleiche alle vier umbenannt:
Effekt aber: keiner, weder positiv noch negativ! Deshalb habe ich sie für die weiteren Versuchen so gelassen.

Es gibt wohl Reparaturwerkzeuge für derartige Probleme, aber meine Erfahrung reicht da leider nicht aus.

Ob ich jetzt endlich die aus fachlicher Sicht "richtigen" Werkzeuge benutzt habe, ist letzendlich egal.
Entscheidend ist, dass die folgenden "Putzmittel" letzendlich wirksam waren.

Schritte:
1. Ausführung der unter der Überschrift:
Re-register DLLs and Recompile MOFs
angegebenen Batch-Datei in
https://support.quest.com/rapid-recover ... repository
danach
2. Ausführung der Liste der 7 Netzwerk-Befehle in:
viewtopic.php?p=394456&hilit=ipconfig+% ... ns#p394456

Dieser äußerst hartnäckige Fehler ist nun schon mal weg. Wow!

von **nohype** » 02.12.2024, 03:08

Fehler-Ausschluss_hinzufuegen.jpg

Das ist die gleiche Fehlermeldung, wie sie ursprünglich beim Rode-Programm auftrat (den dortigen Fehler konnte ich finden und beseitigen).
Sie tritt immer noch auf, hier aber an ganz anderer und umso "ungemütlicherer" Stelle nämlich, wenn ich einen beliebigen Ordner von der Überwachung mit dem Defender mit folgenden Menü-Befehlen ausschließen will:

Code: Alles auswählen

Einstellungen/
Windows Sicherheit/
Viren- & Bedrohungsschutz/
Einstellungen für Viren- & Bedrohungsschutz/
Einstellungen verwalten/
Ausschlüsse hinzufügen oder entfernen/
Ausschluss hinzufügen/
Ordner

Meine Diagnose ergibt hier, dass 4 Textdateien potentiell für den Fehler verantwortlich sind. Sie enthalten alle den fraglichen, früheren Computernamen DESKTOP-F02764I neben z.T. noch älteren, früher benutzten:

Code: Alles auswählen

C:\Windows\debug\NetSetup.LOG
C:\Windows\System32\wmi.txt
C:\Windows\System32\drivers\etc\hosts.ics
C:\Windows\System32\wbem\WMIMigration.log

Da ich die Funktion dieser Dateien aber nicht kenne, habe da noch nichts verändert, der Fehler also weiter besteht, solange ich da nichts verändere.
Naheliegend wäre es, alle vorkommenden auch noch älteren, parasitären Computernamen durch den aktuellen Computernamen manuell zu ersetzen. Dass das zu einer gültigen Konfiguration führen würde, erschein mir aber fraglich.

Es gibt wohl Reparaturwerkzeuge für derartige Probleme, aber meine Erfahrung reicht da leider nicht aus.
Da wäre Eure geschätzte Expertise gefragt.

von **nohype** » 06.11.2024, 18:33

Allerdings eignet sich die zitierte Anleitung auch nur zur Reparatur einer Installation durch Erzeugung eines neuen Accounts. Meine, um aus einer Installation beliebige neue Installationen zu erzeugen.

von **nohype** » 06.11.2024, 18:19

1. Das Ziel meiner Anleitung ist ähnlich der bereits erwähnten:
https://superuser.com/questions/1249772 ... -10-system
2. Unklar bleibt aber deren Ausgangspunkt:
warum ist dort der sysprep-Befehl fehlgeschlagen?
3. Deshalb bleibt auch unklar, warum im Schritt 34 ein neuer Account eingerichtet werden soll. Der ist eigentlich nicht notwendig, da die Behandlung mit sysprep ja bei einer neuen Installation gerade bewirkt, dass ein neuer Account erzeugt wird.
4. Der wahrscheinliche Grund für Schritt 34 ist, dass sysprep nicht funktioniert hat (und überhaupt kein neues install.wim mit dism erzeugt wird).
5. In der o. g. Anleitung werden auch nicht behandelt:
– die Bereinigung des Computernamens in der Zielinstallation
– die Behandlung von bereits in der Ausgangsinstallation (wahrscheinlich) vorhandenen Benutzerprofilen.
Damit diese Benutzerprofile auch in der Zielinstallation zugreifbar sind, müssen deren Passwörter zurückgesetzt werden (mithilfe von Windows Login Unlocker unter WindowsPE – noch vor der Erzeugung von install.wim).
Die Bereinigung des Computernamens müsste dann auch in jedem einzelnen Benutzerprofil in der Zielinstallation erfolgen.

von **nohype** » 06.10.2024, 05:04

Ich habe nun mit meiner Anleitung einmal ein Installationsmedium auf der Basis einer Windows 10-ISO hier aus dem Wiki hergestellt, nur um herauszubekommen, wo sich - mindestens - die Reste des alten Computernames der Basisinstallation in der Zielinstallation verewigen: an diversen Stellen. Eine geeignete habe ich herausgesucht, um damit den alten Computernamen mittels des RegRead-Befehls von AutoHotkey in der Zielinstallation zu extrahieren. Damit kann dann der Umweg über eine Hilfsumgebungsvariable in der Basisinstallation mit dem setx-Befehl vermieden werden. Er ist nicht mehr erforderlich, sodass Schritt 2, s. o., wegfällt.
Das AHK-Skript für das Ersetzen der Reste des alten Computernamens durch den neuen, sieht dann so aus:
ComputernamenErsaetzen.ahk

Code: Alles auswählen

Run, "C:\Users\Public\Desktop\RegistryFinder-32Bit\RegistryFinder.exe"
RegRead, OutputVar, HKEY_LOCAL_MACHINE, SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\Fax\DsSpooler, shortServerName
Sleep, 100
altername := OutputVar,
Sleep, 100
neuername := COMPUTERNAME,
WinWait, Registry Finder - [Local Registry], 
IfWinNotActive, Registry Finder - [Local Registry], , WinActivate, Registry Finder - [Local Registry], 
WinWaitActive, Registry Finder - [Local Registry], 
Send, {CTRLDOWN}f{CTRLUP}
WinWait, Find, 
IfWinNotActive, Find, , WinActivate, Find, 
WinWaitActive, Find, 
Sleep, 1
Send, %altername%{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{ENTER}
WinWait, Registry Finder - [Find Results - %altername%], 
IfWinNotActive, Registry Finder - [Find Results - %altername%], , WinActivate, Registry Finder - [Find Results - %altername%], 
WinWaitActive, Registry Finder - [Find Results - %altername%], 
Send, {CTRLDOWN}r{CTRLUP}
WinWait, Replace, 
IfWinNotActive, Replace, , WinActivate, Replace, 
WinWaitActive, Replace, 
Send, %altername%{TAB}%neuername%{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}

von **nohype** » 03.10.2024, 04:10

Um in der Zielinstallation noch Reste vom Computernamen der Basisinstallation in der Zielinstallation zu beseitigen, wird ein AHK-Skript (Installationspaket AutoHotkey104805_Install.exe) benutzt, das bereits in die Basisinstallation integriert wird.

Folgende Schritte sind in der Basisinstallation vor der Abarbeitung der obigen Anleitung zur Erstellung des install.wim Archivs auszuführen:

1. Installiere AutoHotkey.

2. ALTNAME ist eine Hilfs-Umgebungsvariable, die die Systemvariablen von Windows ergänzt.

Führe in einer Kommandozeile mit Administratorenrechten aus:

Code: Alles auswählen

setx ALTNAME %COMPUTERNNAME% /M

3. Das folgende AHK-Script CleanUpOldComputername.ahk beseitigt Reste des Computernamens der Basisinstallation in der Zielinstallation:

Code: Alles auswählen

Run, "C:\Users\Public\Desktop\RegistryFinder-32Bit\RegistryFinder.exe"
WinWait, Registry Finder - [Local Registry], 
IfWinNotActive, Registry Finder - [Local Registry], , WinActivate, Registry Finder - [Local Registry], 
WinWaitActive, Registry Finder - [Local Registry], 
Send, {CTRLDOWN}f{CTRLUP}
WinWait, Find, 
IfWinNotActive, Find, , WinActivate, Find, 
WinWaitActive, Find, 
Send, %altername%{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{ENTER}
WinWait, Registry Finder - [Find Results - %ALTNAME%], 
IfWinNotActive, Registry Finder - [Find Results - %ALTNAME%], , WinActivate, Registry Finder - [Find Results - %ALTNAME%], 
WinWaitActive, Registry Finder - [Find Results - %ALTNAME%], 
Send, {CTRLDOWN}r{CTRLUP}
WinWait, Replace, 
IfWinNotActive, Replace, , WinActivate, Replace, 
WinWaitActive, Replace, 
Send, %ALTNAME%{TAB}%COMPUTERNAME%{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}

Es wird ins Verzeichnis:

C:\Users\Public\Desktop

kopiert.

Durch diesen Speicherort steht es dann auf dem Desktop der Zielinstallation zur Verfügung.

4. Entpacke in das gleiche Verzeichnis das Archiv RegistryFinder-32Bit.zip. Diese Version erfordert keine Installation.

Für die Aktionen im Verzeichnis C:\Users\Public\Desktop sind jeweils Administratorenrechte erforderlich.

5. In den Eigenschaften des Programms RegistryFinder.exe ist die Kompatibiltät explizit auf "Programm als Administrator ausführen" einzustellen.

von **nohype** » 30.09.2024, 13:29

Nun muss man noch einen brauchbaren Weg finden, um die immer noch vorhandenen Reste des alten Computernamens in der Registrierung der mit dem Installationsmedium erzeugten neuen Installation zu ersetzen.
Mit dem folgenden AutoHotKey-Skript (Legacy-Version! von AutoHotKey) und der 32-Bit-Version von Registry Finder geht das.
Der Code ist als Datei mit der Endung ahk ausführbar.

Code: Alles auswählen

Run, "E:\drivers\Registry-Tools\RegistryFinder-32Bit\RegistryFinder.exe"
altername := "DESKTOP-F02764I",
neuername := "DESKTOP-K166J20",
  WinWait, Registry Finder - [Local Registry], 
IfWinNotActive, Registry Finder - [Local Registry], , WinActivate, Registry Finder - [Local Registry], 
WinWaitActive, Registry Finder - [Local Registry], 
Send, {CTRLDOWN}f{CTRLUP}
WinWait, Find, 
IfWinNotActive, Find, , WinActivate, Find, 
WinWaitActive, Find, 
Send, %altername%{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{ENTER}
WinWait, Registry Finder - [Find Results - %altername%], 
IfWinNotActive, Registry Finder - [Find Results - %altername%], , WinActivate, Registry Finder - [Find Results - %altername%], 
WinWaitActive, Registry Finder - [Find Results - %altername%], 
Send, {CTRLDOWN}r{CTRLUP}
WinWait, Replace, 
IfWinNotActive, Replace, , WinActivate, Replace, 
WinWaitActive, Replace, 
Send, %altername%{TAB}%neuername%{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}

Sinnvoll ist das Script allerdings so nicht, da ja die Variablenwerte von altername und neuername für die Computernamen jeweils von Hand eingegeben und gespeichert werden müssen.
In der nächsten Version werden diese Werte dann durch das Skripts selbst durch Auswerten der Windows-Umgebungsvariablen COMPUTERNAME (der Ausgangs- bzw. der mit dem Installationsmedium erzeugten Installation) ermittelt.

von **nohype** » 24.09.2024, 15:03

In der Anleitung habe ich zur Erzeugung eines Installationsmediums ct-wimage benutzt uzw. durch Ersetzen der install.wim-Datei im sources-Ordner.
Alternativ kann man als Basis für das zu erzeugende Installationsmediums Rufus benutzen:
zunächst wird unter Verwendung einer Windows 10-ISO-Imagedatei mit Rufus ein Windows 10 Installationsmedium hergestellt.
Dort überschreibt man wieder im sources-Ordner des erzeugten Installtionsmediums die Datei install.wim mit der mit dem dism-Befehl erzeugten install.wim-Datei.

von **nohype** » 15.09.2024, 15:01

Um nun die größtmögliche Verwirrung zu stiften:
Hier eine entscheidende Vereinfachung:
Folge der Anleitung nur bis zur Nr.2, aber strikt, also ohne die Korrektur in meinem vorigen Posting.

nohype hat geschrieben: 14.08.2024, 06:22 Der scheinbar überflüssige Zwischenschritt nach Methode 4 ist doch notwendig, weil ohne ihn kein neuer Computername erzeugt wird. Kollisionen durch gleiche Benutzernamen im lokalen Netzwerk können vermieden werden, weil bei einer neuen Installation mit dem CT-WIMAGE Installationsmedium in Schritt 10 auch jeweils die Vergabe eines neuen, frei wählbaren Benutzerkontonamens möglich ist.
Die folgende doppelte Erzeugung eines Images "install.wim" ist notwendig.
Schritte:
1. Man kopiert eine vorhandene W10-Musterinstallation als Arbeitskopie auf eine andere SSD-Platte und arbeitet dann ausschließlich mit dieser.
2. Man startet eine WindowsPE-Version (z.B. ct-notwin oder PhoenixPE, die Windows Login Unlocker enthalten) und bearbeitet die Arbeitskopie nach Methode 4. Wichtig: die zur Bearbeitung geladene Registrierungsstruktur der Arbeitskopie muss wieder mit "Struktur entfernen" entladen werden, sonst funktiert der folgenden dism-Befehl nicht.
3. Von der so bearbeiteten Arbeitskopie erzeugt man mit dism eine Imagedatei "install.wim" und kopiert diese in das sources-Verzeichnis der 2. Partition von ct-wimage oder schreibt das Image direkt auf die CT-WIMAGE-Partition.
4 Nach dem Neustart mit diesem CT-Wimage Installationsmedium erzeugt man auf derselben SSD wieder eine neue Arbeitskopie.
5. Auf die gestartete neue Arbeitskopie wendet man sysprep - wie oben angegeben - an.
6. Danach den Rechner sofort wieder herunterfahren: kein Neustart(!).
7. WindowsPE (Notwin oder PhoenixPE) wieder starten.
7a. nicht mehr benötigte lokale Profilverzeichnisse C:\Users\[User] können gelöscht werden.
8. Mit dism wieder ein neues Image mit Namen "install.wim" erzeugen.
9. das "install.wim" im "sources"-Ordner auf der 2. Partition des ct-wimage Installationssticks wieder mit dem neu erzeugten überschreiben
10. Mit diesem so gewonnenen ct-wimage Installationsmedium kann Windows 10 auf beliebigen Rechnern installiert werden, mit jeweils neuem Computernamen.
Der benutzte dism-Befehl ist immer der gleiche:
dism /Capture-Image /ImageFile:: [G:]\sources\install.wim /CaptureDir:C:\ /Name:Drive-C
Als Pfad des Images kann immer [G:]\sources\install.wim des Volumes "CT-WIMAGE" benutzt werden. Dann spart man sich das Überschreiben von install.wim im [G:]\sources Ordner.
Mit der angegebenen Methode ist es mir nicht gelungen neue SIDs zu erzeugen.

Nach vollständiger Abarbeitung der Methode 4 in Nr. 2, fährt man dort direkt mit Nr.5 fort(!)
Es muss nach dieser Anleitung also nur noch ein einziges install.wim für ct-wimage erzeugt werden.

von **nohype** » 15.09.2024, 14:39

Meine Anleitung ist irreführend.
Korrektur:
In Methode 4
https://superuser.com/questions/1249772 ... -10-system
heißt es in den Schritten:

...
33. Close regedit and go to the Windows Login Unlocker
34. Add a new user.
35. Shut down, remove USB, and boot into Windows.
36.Log in to the new user.
...

Methode 4 sollte also nur bis Nr. 34 abgearbeitet werden, also danach kein Neustart erfolgen, sondern ein neues

Code: Alles auswählen

install.wim

erzeugt werden, um danach mit Nr. 3 meiner Anleitung fortzufahren.

von **nohype** » 26.08.2024, 02:42

Warum sich SIDs mit sysprep (analog wohl mit NewSID) - wie in meinem Falle - nicht ändern lassen, erklärt @iMil, wie folgt:

c't-WIMage für die Einrichtung mehrerer Rechner

https://www.heise.de/forum/c-t/Kommenta ... 9840/show/

von **nohype** » 16.08.2024, 20:40

Weder mit Sysprep noch mit NewSID konnte ich bisher SIDs ändern.
Mit einem Trialkey von
https://www.stratesave.com/html/sidchg.html
scheint es aber machbar zu sein:

Sicherheitskennung (sid) unter Windows 10 ändern | Ändern Sie die SID von Windows 10 ohne Sysprep

https://www.youtube.com/watch?v=4fImvgWayI0

von **nohype** » 14.08.2024, 06:22

Der scheinbar überflüssige Zwischenschritt nach Methode 4 ist doch notwendig, weil ohne ihn kein neuer Computername erzeugt wird. Kollisionen durch gleiche Benutzernamen im lokalen Netzwerk können vermieden werden, weil bei einer neuen Installation mit dem CT-WIMAGE Installationsmedium in Schritt 10 auch jeweils die Vergabe eines neuen, frei wählbaren Benutzerkontonamens möglich ist.
Die folgende doppelte Erzeugung eines Images "install.wim" ist notwendig.
Schritte:
1. Man kopiert eine vorhandene W10-Musterinstallation als Arbeitskopie auf eine andere SSD-Platte und arbeitet dann ausschließlich mit dieser.
2. Man startet eine WindowsPE-Version (z.B. ct-notwin oder PhoenixPE, die Windows Login Unlocker enthalten) und bearbeitet die Arbeitskopie nach Methode 4. Wichtig: die zur Bearbeitung geladene Registrierungsstruktur der Arbeitskopie muss wieder mit "Struktur entfernen" entladen werden, sonst funktiert der folgenden dism-Befehl nicht.
3. Von der so bearbeiteten Arbeitskopie erzeugt man mit dism eine Imagedatei "install.wim" und kopiert diese in das sources-Verzeichnis der 2. Partition von ct-wimage oder schreibt das Image direkt auf die CT-WIMAGE-Partition.
4 Nach dem Neustart mit diesem CT-Wimage Installationsmedium erzeugt man auf derselben SSD wieder eine neue Arbeitskopie.
5. Auf die gestartete neue Arbeitskopie wendet man sysprep - wie oben angegeben - an.
6. Danach den Rechner sofort wieder herunterfahren: kein Neustart(!).
7. WindowsPE (Notwin oder PhoenixPE) wieder starten.
7a. nicht mehr benötigte lokale Profilverzeichnisse C:\Users\[User] können gelöscht werden.
8. Mit dism wieder ein neues Image mit Namen "install.wim" erzeugen.
9. das "install.wim" im "sources"-Ordner auf der 2. Partition des ct-wimage Installationssticks wieder mit dem neu erzeugten überschreiben
10. Mit diesem so gewonnenen ct-wimage Installationsmedium kann Windows 10 auf beliebigen Rechnern installiert werden, mit jeweils neuem Computernamen.
Der benutzte dism-Befehl ist immer der gleiche:
dism /Capture-Image /ImageFile:: [G:]\sources\install.wim /CaptureDir:C:\ /Name:Drive-C
Als Pfad des Images kann immer [G:]\sources\install.wim des Volumes "CT-WIMAGE" benutzt werden. Dann spart man sich das Überschreiben von install.wim im [G:]\sources Ordner.
Mit der angegebenen Merhode ist es mir nicht gelungen neue SIDs zu erzeugen.

Documents-Ordner [gelöst]

Antwort erstellen

Ansicht erweitern Die letzten Beiträge des Themas: Documents-Ordner [gelöst]

Re: Documents-Ordner

[gelöst] Re: Documents-Ordner

Re: Documents-Ordner

Re: Documents-Ordner

Re: Documents-Ordner

Re: Documents-Ordner

Re: Documents-Ordner

Re: Documents-Ordner

Re: Documents-Ordner

Re: Documents-Ordner

Re: Documents-Ordner

Re: Documents-Ordner

Re: Documents-Ordner

Re: Documents-Ordner

Re: Documents-Ordner