Benutzer-Verzeichnis verschieben/umlenken wird von Win 10 nicht richtig angenommen

[W10user]

Hallo im Neuen jahr,

ich habe mein Windows 10 noch immer noch nur auf der zweiten Partition meiner kleinen SSD und stehe vor einem Problem.

Meine SSD ist recht klein. Ich brauche auch nicht wirklich mehr. Denn ich habe in meinem Computer zwei HDDs

Unter Windows 7 ist auch kein Problem. Hier konnte ich Mühelos mein gesamtes Profil auf eine HDD umlenken.

Hierfür musste ich mich nur mal kurz an und wieder abmelden. Das erstellte Profileverzeichnis auf die HDD verschieben und mit mklink eine "Verknüpfung" auf HDD erstellen.

Es klappte sehr einfach und es gab nie Probleme


Gleiches Versuchte ich mehrfach schon unter Windows 10 auch. Doch bin damit immer gescheitert.

Nicht das es nicht ging. Doch nach der Anmeldung lief einfach das Startmenü nicht mehr.

Die CPU Auslastung ging auf 100% und eine Datei bzw. Dienst names C:\WINDOWS\system32\backgroundTaskHost.exe begann sich alle 5-10 Sekunden neu zustarten.

Nach wenigen Minuten wurde ich auch wieder Zwangsabgemeldet und konnte nur in ein nicht verlinktes Profil wechseln.

Kennt jemand zufällig die Ursache für dieses Verhalten?


Ich fand im Netz schon Hinweise, dass man einfach die Dokumente und Bilder und Videos einfach auf die HDD verschieben soll. Doch das ist keine wirkliche Lösung.

Das Problem ist ja %appdata% und %localappdata%. Das sind die waren Arbeitsverzeichnisse von Windows. Auch die Temp-Dateien sind hier zu finden. Unter meinem Windows 7 sind die Verzeichnisse gut 50 GB in Nutzung. Während ich mir GIMP und Co. arbeite, werden die Ordner manchmal auch 100 GB.

Die SSD ist nur 128 GB gross. (111 GB eigentlich)

Hier sind noch Reste von meinen Versuchen zu sehen...

C:\Users>dir
 Datenträger in Laufwerk C: ist Win10
 Volumeseriennummer: XXXX-XXXX

 Verzeichnis von C:\Users
...
...         <JUNCTION>     work [\??\D:\Users\work]
...         <SYMLINKD>     work.SYMLINKD [D:\Users\work]

               1 Datei(en),              0 Bytes
              12 Verzeichnis(se),  9.394.147.328 Bytes frei
...

9 GB sind längst nicht mehr genug Reserve. Aber das liegt auch nur daran, dass das Profil Verzeichnis vor Daten nur so platzt. Dabei ist es nicht mal richtig gefüllt.
Die Daten sollen ja wie erwähnt alle auf mein D... wo genug Platz ist.

C:\Users>dir D:
 Volume in Laufwerk D: hat keine Bezeichnung.
 Volumeseriennummer: XXXX-YYYY

 Verzeichnis von D:\

20.09.2017  19:34    <DIR>          Users
19.12.2017  18:02    <DIR>          VirtualBox
               0 Datei(en),              0 Bytes
               5 Verzeichnis(se), 3.767.221.972.992 Bytes frei

Nun hoffe ich, dass hier jemand vielleicht die Ursache kennt. Vielleicht ist es nur ein Dienst, den man sowieso nicht braucht. Ich vermute ganz es ist Contana bzw. die Windows Suche, die als Dienst immer mitlaufen. Oder es ist der Windows Store, welcher aber eigentlich ganz wonders seine Daten ablegt.

 

[areiland]

Den kompletten Benutzerordner verschiebt man eben nicht mit Steinzeitmethoden! Windows toleriert das nur, wenn man die Ordner mt den eigenen Dateien verlegt. Der einzige Weg, die Benutzerordner auf ein eigenes Laufwerk zu verlegen, führt darüber dass man den Inhalt von C:\Users auf das andere (NTFS formatierte) Laufwerk verschiebt und dieses dann in den leeren Ordner C:\Users einhängt. Nur auf diese Weise bleiben sämtliche relativen und absoluten Bezüge erhalten .

 

[W10user]

Den kompletten Benutzerordner verschiebt man eben nicht mit Steinzeitmethoden! Windows toleriert das nur, wenn man die Ordner mt den eigenen Dateien verlegt. Der einzige Weg, die Benutzerordner auf ein eigenes Laufwerk zu verlegen, führt darüber dass man den Inhalt von C:\Users auf das andere (NTFS formatierte) Laufwerk verschiebt und dieses dann in den leeren Ordner C:\Users einhängt. Nur auf diese Weise bleiben sämtliche relativen und absoluten Bezüge erhalten .

Steinzeitmethoden?

Es Stimmt. Unter dem Steinzeit-System Unix kann man seit anbeginn des modernen Computerzeitalters jedes Verzeichnis, auch das Nutzerverzeichnis einfach auf eine andere Parition/Festplatte mounten.

Entweder in der fstab oder als symbolischer Link.

Aber ganz davon abgesehen, hab ich doch geschrieben, dass ich alles Verlegt hatte. Alle Documents, alle AppData. Das gesamte Profil erstmal erstellt. Dann auf D verschoben und dann noch verlinkt.

und gibt man ... dir /A %USERPROFILE% ein...
.. findet man sowas...
<JUNCTION> Anwendungsdaten [C:\Users\user\AppData\Roaming]
<JUNCTION> Eigene Dateien [C:\Users\user\Documents]
<JUNCTION> Recent [C:\Users\user\AppData\Roaming\Microsoft\Windows\Recent]

Und die habe ich ganz bestimmt nicht angelegt. Das war Windows selbst. Mit seinen eigenen Steinzeitmethoden, die erst mit Vista/7 überhaupt eingeführt wurden. (Unter 2000 gab es das auch schon aber noch nicht benutzt)


Der Grund warum ich nebenbei nur ein Profilverzeichnis umlenken möchte, ist nebenbei gerade die Stabilität.
Für Administrative Aufgaben, sollte das Admin Profil weiterhin auf der SSD bleiben. Denn vielleicht muss ich auch mal die Zweite Festplatte Austuaschen/Warten Da wäre es sehr schlecht, wenn sie gerade vom System benutzt wird und es deshalb nicht mehr hochfahren kann, weil der Profildienst sein Verzeichnis nicht mehr findet.

Deshalb gibt es auch unter Unix/Linux ein /root im Hauptverzeichnis und nicht in den Nutzer-Profilverzeichnis, wie es leider... ja....
... Im Grunde lebt Windows noch in der Steinzeit bzw. macht sogar eine Rückentwicklung, da es früher zumindest mal funktioniert.

Dabei ist gerade Windows ja so kompatible zu seinen Vorgängerversionen bzw. deren Programmen. Schade leider.


Falls trotzdem jemand noch eine Idee hat, wie man dieses Crashverhalten genauer ausfindig machen könnte, würde ich mich gerne über eine Meldung freuen.


PS: Ich frage mich gerade, ob es vielleicht auch an der Version hängt. Im heimischen Kosumerbereich kann ich leider nur auf die Professional zurückgreifen.
Eben habe ich nochmal ein KB zum Thema gefunden. https://support.microsoft.com/en-us/help/949977 - Hier wird vom Server gesprochen, das es sogar die Performance verbessert.

"There are performance improvements when you relocate the Users directory and the ProgramData directory to a drive other than the operating system drive."

Könnte ich mit der Enterprise Edition oder gar Server Edition mehr "Glück" haben?

 

[areiland]

Windows ist kein Linux oder Unix! Da gelten einfach andere Regeln und die besagen, dass Benutzerverzeichnisse nicht mit Symlinks oder Hardlinks verschoben werden können. Hier sind Mountpoints zu setzen - eine Vorgehensweise, die auch unter den unixoiden Betriebssystemen üblich und in der fstab nur dokumentiert ist, weil daraus die Mountpoints entnommen werden müssen. Bei Windows werden die Mountpoints hingegen im Dateisystem hinterlegt, damit sie auch dann gültig sind, wenn eine andere Instanz (WinRE) des Systems läuft. WinRE würde eine angedachte "fstab" des anderen Systems gar nicht auswerten und so deren Mountpoints nicht beachten können. Ein Windows wird bei Updates oder Upgrades aber gar nicht aus dem laufenden System heraus aktualisiert, sondern von WinPE aus, von daher laufen die Steinzeitmethoden (bis Windows XP möglich - bei Vista und 7 nur noch toleriert) voll ins Leere.

Verlege die Benutzerordner mit der von mir gezeigten Methode, dann funktioniert es auch.

 

[Fritz0312]

@ areiland
Sie geben einen Tipp, wie man auch unter Win10 das Benutzerkonto auf eine andere Partition/Festplatte verschieben kann. Wie genau geht das?
Ich würde mich ebenso wie viele andere freuen, über eine Anleitung.

Dieses Problem haben viele Nutzer, insbesondere seit es neue Rechner mit kleinen SSDs für die Programme mit einer weiteren HDD für die Daten gibt.
Die Datenmengen, die unter AppDate von Programmen hinterlegt werden, sind teilweise immens (z.B. Google Earth). Es ist ein Unding seitens Microsoft, hier kein einfache Möglichkeit zu bieten, die auch ein "normalversierter" Nutzer umsetzen kann.

Mit Dank voraus - Fritz

 

[Sabine]

Hier ist die Anleitung:

https://www.win-10-forum.de/windows-10-faq/668-benutzerordner-verlegen.html

Aber: Es geht "nur" darum, die Benutzerordner zu verlegen. Von Benutzerkonto oder AppData ist nie die Rede gewesen. Davon sollte man die Fingerchen lassen. Außer man möchte ein nicht mehr funktionsfähiges System riskieren.

Vielleicht nur eine rhetorische Frage. Was hat Microsoft mit kleinen SSD's zu tun? Frag doch die Hardware-Hersteller, warum sowas verkauft (und gekauft!!!!) wird.

Liebe Grüße

Sabine

 

[Wolf.J]

Das Problem mit übervollen Systemordner unter %appdata% ist nicht Microsoft, gedacht ist das ja eingentlich nur, um bestimmte Informationen zu hinterlegen, die per se nicht viel Platz beanspruchen.
Wenn man sich allerdings ansieht, was einige Installationen da ablegen, dann wird es einem ganz schlecht, das geht bis zu DLLs und anderen Programmteilen, die hier versteckt werden, obwohl sie definitiv in die Programmverzeichnisse gehören.
Der Gau auf dem Rechner meines Sohnes waren 99 GB aus einem einzigen Steam-Spiel, damals auf eine 250er SSD.
Die mussten dann nach Deinstallation noch manuell gelöscht werden! Also absolut unsauber programmiert. Und dafür kann Microsoft nichts.
Es gibt übrigens auch Installationsroutinen, die es dem User ermöglichen, die Nutzung von %appdata% zu verbieten, wie z. B. der Editor Notepad++.

An einer vernünftigen Methode, %appdata% zu verlegen bin ich natürlich auch interessiert. aber zum heutigen Stand lasse ich die Finger davon.

 

[areiland]

Man kann mit der oben angedeuteten Methode "Mountpoints", also dem einbinden von Partitionen in einen leeren Ntfs Ordner, praktisch jeden Ordner weg von der Systempartition verlegen. Nur geht das nicht aus dem laufenden System heraus. Hier wäre also richtig Handarbeit angesagt, weil man das dann von WinRE aus in einer Eingabeaufforderung vornehmen muss. Dazu wäre der gesamte Inhalt des Ordners auf die einzubindende Partition zu verschieben und diese dann mit Hilfe von Diskpart: https://docs.microsoft.com/de-de/windows-server/storage/disk-management/assign-a-mount-point-folder-path-to-a-drive im nun leeren Ordner bereitzustellen.

Da diese Bereitstellungen nicht an Laufwerksbuchstaben gebunden sind, sondern an die VolumeID, können sich die Laufwerksbuchstaben verschieben wie sie lustig sind - es juckt Windows nicht. Und genau deshalb ist diese Methode auch die einzige, die machbar ist ohne in Probleme zu laufen.