Anzeige

Am Puls von Microsoft

Anzeige

Den Namen des Benutzerverzeichnisses korrigieren

G

Gast598

Gast
Hallo Community, :)

mein neues System steht schon seit etlichen Stunden auf festem Fuß und es läuft wie zu erwarten, gut.
Scheinbar hat sich die CPUVID verringert - der werde ich noch an der Vcore beobachten, sobald ich die passenden Tools installiert und eingerichtet habe, doch zuerst das Wichtigste.



Unbenannt.PNG

Es mag nur ein optisches Gimmick sein, doch mir gefällt es nicht, ich identifiziere mich damit nicht.
Die zurückgespielten Konfigurationen von einst <KnSNaru> nach aktuell <knsna> werden übernommen, unter älteren Betriebssystemen undenkbar gewesen, sodass ich davon ausgehen kann, dass <knsna> lediglich ein übergeordneter Softlink ist, der auf den harten String <KnSNaru> verweist, dennoch gefällt mir das nicht - es sieht komisch aus und lässt dieses Benutzerverzeichnis si unwirklich, schlampig wirken.

Hat wer eine Idee, wie das zu ändern geht? Der Name des Benutzerkontos wirkt sich darauf nicht aus!

Quelle zum ursächlichen Problemfall:
https://www.drwindows.de/windows-10-desktop/135567-erster-freeze-redstone-3-ursache-unbekannt.html

In der Zwischenzeit lese ich mich hierin durch:
https://www.drwindows.de/windows-anleitungen-faq/65038-benutzerordner-nachtraeglich-umbenennen.html

Oh ja, das scheint vielversprechend zu wirken! ^^ - Ich hab nur kein anderes Windows! xD

LG,
Naru! :)
 
Anzeige
Ich habe die Methode verlinkt. Man kann alles ändern, es braucht nur die richtigen Schritte! ^^
 
Und riskierst ein geschrottetes Benutzerprofil - unnütze Aktion, ganz ehrlich. Mach einfach das, was danach steht - neues Profil und Daten kopieren - erspart allen Arbeit. Falls nicht - du wurdest gewarnt.
 
Hallo,

ich finde mich damit ab, aber nur deswegen, weil es im Kern der gleiche Benutzername ist, denn offenbar finden die Anwendungen die Konfigurationen von "KnSNaru" ebenso über "knsna".

Alleine schon dieser kleine Unterschied im Benutzernamen der Lokalen Anwendungsdaten sorgt in den früheren Windows-Versionen für Probleme, auch unter Windows Vista, wo es schon das neue Konzept ist, dann muss man dies in den Konfigurationsdateien der Anwendungen anpassen, insofern möglich, andernfalls findet die betreffende Anwendung die gewünschten Daten nicht, weil es auf das aktuell anders benannte Benutzerverzeichnis zugreift. Auch das kann man anpassen, dass die Anwendung wie Firefox über ein anderes Benutzerverzeichnis zugreift, was so benannt ist, wie es in den Einstellungsdateien hinterlegt ist, dennoch wandern die anderen, dem aktuellen Benutzer betreffenden Einstellungen in das aktuelle Benutzerverzeichnis, sodass nur Bestandteile der Konfigurationen übernommen werden. Wer in der Vergangenheit so Spieleinstellungen gesichert hat wird das kennen und er hat sich trotz derer Sicherung und dem Zurückspielen letztendlich gewundert, dass die zurückgespielten Einstellungen nicht eingelesen werden können - weil der Benutzername, der Root, ein anderer ist.


Wer die Zuordnung und die Benennung von den Anwendungs- und Einstellungsverzeichnissen seit der Einführung von NT-6 noch nicht verstanden hat - die Verzeichnisse in direkter Gegenüberstellung.

die Benutzereinstellungen unter NT-5
<C:\Documents and Settings\*User*\Application Data\> = dem Benutzer übergreifende Programmeinstellungen

<C:\Documents and Settings\*User*\Local Settings\Anwendungsdaten\> = des Benutzers lokale Programmeinstellungen

<C:\Program Files\> = die Ausführungsdateien, die Programmerweiterungen und die Anwendungseinstellungen mit erhöhtem Benutzerrecht/mit uneingeschränktem Schreibrecht


die Symbiose von NT-6 gegenüber NT-5
<C:\Users\*User*\AppData\Roaming\> = dem Benutzer übergreifende Programmeinstellungen

<C:\Users\*User*\AppData\Local\> = des Benutzers lokale Programmeinstellungen

<C:\Program Files (x86)\> & <C:\Program Files\> = die Ausführungsdateien, die Programmerweiterungen und die Anwendungseinstellungen mit normalem Benutzerrecht/mit eingeschränktem Schreibrecht (die Änderung gegenüber NT-5, weiter siehe nächster Punkt)

<C:\Users\*User*\AppData\LocalLow\> = wie schon von <C:\Users\*User*\AppData\Local\> handelt es sich um diejenigen lokalen Programmeinstellungen, diese dem Systemadminstrator (equal Power User Mode) unterstellt sind - kein Wunder, dass ihr darunter die Einstellungen zur Java Runtime Environment vorfindet, denn auf ihre Konfigurationsebene erhält der Benutzeradministator keine Berechtigung, diese muss er sich von dem *Remote Procedure Call Locator - LRPC erstatten

*Die Kontrolle über den Remote Procedure Call Locator - LRPC kann sich der Benutzer nicht aneignen, diese sichereheitsrelevante Hintertür durch den sogenannten Power User (der Benutzer - dem Systemadminstrator gleichgestellt) ist seit NT-6 vorüber!
Der Benutzer kann sich bestenfalls die Berechtigung über das Distributed Component Object Model - DCOM einholen, dieses gestattet es bspw. den Windows Explorer als Administrator ausführen zu dürfen, erweiterte Prozessdurchläufe durch den LRPC ein zu holen, doch ihm kommt der Benutzer nicht gleich - er muss stets die Erlaubnis über ihn einholen und dies gilt ebenso für das DCOM, welcher dem LRPC unterstellt ist und auf dessen Level der Benutzer sich im Höchstfall bewegen darf!



die Neuerung von NT-6 gegenüber NT-5
<C:\ProgramData\> = der Anwendung spezifische Programmerweiterungen und Ausführungsdateien von <C:\Program Files\> und <C:\Program Files\Common Files\>mit erhöhtem und übergeordnetem Benutzerrecht; - die Auslagerung der von den Benutzern übergreifenden, gemeinsamm genutzten Programmeinstellungen und Programmerweiterungen

<C:\Users\*User*\AppData\Local\VirtualStore\> = die lokalen Programmeinstellungen von eingeschränkter Konnektivität und eingeschränktem Lese- und Schreibrecht (die Benutzerkontensteuerung und die Registrierung von einer Anwendung sind dafür verantwortlich, dass Windows die Einstellungen von beispielsweise einem Spiel in dieses Verzeichnis ablegt; - wenn die gesicherten Einstellungsdateien aus diesem Verzeichnis nach einer erneuten Installation von Windows nicht angewendet werden dann sind diese Dateien gemäß dem hinterlegten Stammbaum von bspw. <C:\Users\*User*\AppData\Local\VirtualStore\Program Files (x86)\Thaiphoon Burner\> nach <C:\Program Files (x86)\Thaiphoon Burner\> zu übertragen, weil sich diejenige Anwendung gegenüber der vorhergehenden Windows-Installation mit Lese- und Schreibrecht registriert hat; - unter Umständen erfordert diejenige Anwendung im Gegenzug die Ausführung mit administrativen Rechten, um zu starten oder um diese Einstellungen ein zu lesen und darin zu schreiben

Die Neuerungen ind er Dateistruktur von Windows sind nicht verwirrend, sie sind logisch nach zu vollziehen, wenn man sich mit deren Funktion auseinandergesetzt hat.
 
Zuletzt bearbeitet:
tl;dr

Du kannst da gerne weiter in medias res gehen, das wird kaum jemanden in seinem Standpunkt ändern.
 
Das wollen wir mal nicht hoffen, sonst bist Du dazu angewiesen auf Dr. Windows Überstunden zu absolvieren! ^^
 
Ich werd mich garantiert dann nicht in deine Probleme reinhängen. Zum einen dürftest du das ganz gut ohne uns lösen können, zum anderen bin ich mit Linux beschäftigt. Und dann sind da noch die Feiertage, wovon ich ich Mittwoch Vormittag eine Drei-Wege-Klappe ans Laufen kriegen darf - also nicht zu hause bin, sondern über Los gehe und 100% Extra einsacke.


:D :D :D
 
Warum sollte man krampfhaft versuchen, den Namen seines Benutzerordners zu ändern? Wenn man den unbedingt sehen möchte, dann reicht es doch aus im Explorer über einen Rechtsklick alle Ordner einblenden zu lassen. Schon steht der Benutzerordner so prominent im Explorer, dass man auf jeden Blick in den Benutzerordner verzichten kann.
 
Bei Änderung des Benutzernamens gegenüber der vorherigen Installation sollte man bedenken, dass einige Backup-Programme damit Schwierigkeiten haben, z. B. MOBackup.
 
Ach ... areiland!

@Jürgen, gehen tut das schon - der Link da zeigt, wie es geht. Ich habe nur kein zweites OS zur Hand und ich mache mir *deswegen* nicht die Mühe eines Live hoch zu fahren.

Die Kunst ist nicht das Umbenennen des Ordners, obwohl man das nur im Offline-Modus hinkriegt, sondern die Übernahme aller Anwendungen auf dieses Verzeichnis sowie der Dateien im Ordner. Ich befürchte, dass das nicht ohne Komplikation vonstatten geht. Ich habe erst einen Dateisystemfehler hinter mich gebracht, den aber liebend gerne genauso gut gelöst bekommen hätte, aber jetzt steht das neue System, bis auf dessen kleinliche Konfigurationen und einigen Anwendungen ist es fast auf den alten Stand.

Im Übrigen habe ich auch auf diesem neuen System einige Events 10016, aber diese stören mich nicht, sie scheinen sich nicht gravierend bemerkbar zu machen und sie scheinen bisher nur zwei zu sein.

Durch die Berechtigungseinstellungen für "Anwendungsspezifisch" wird dem Benutzer "KNSNARU-PC\KnSNaru" (SID: S-1-5-21-1180252540-518409225-2340446890-1001) unter der Adresse "LocalHost (unter Verwendung von LRPC)" keine Berechtigung vom Typ "Lokal Aktivierung" für die COM-Serveranwendung mit der CLSID
{D63B10C5-BB46-4990-A94F-E40B9D520160}
und der APPID
{9CA88EE3-ACB7-47C8-AFC4-AB702511C276}
im Anwendungscontainer "Nicht verfügbar" (SID: Nicht verfügbar) gewährt. Die Sicherheitsberechtigung kann mit dem Verwaltungstool für Komponentendienste geändert werden.

Durch die Berechtigungseinstellungen für "Anwendungsspezifisch" wird dem Benutzer "NT-AUTORITÄT\Lokaler Dienst" (SID: S-1-5-19) unter der Adresse "LocalHost (unter Verwendung von LRPC)" keine Berechtigung vom Typ "Lokal Aktivierung" für die COM-Serveranwendung mit der CLSID
{6B3B8D23-FA8D-40B9-8DBD-B950333E2C52}
und der APPID
{4839DDB7-58C2-48F5-8283-E1D1807D0D7D}
im Anwendungscontainer "Nicht verfügbar" (SID: Nicht verfügbar) gewährt. Die Sicherheitsberechtigung kann mit dem Verwaltungstool für Komponentendienste geändert werden.


Im Zusammenhang mit:

Beim Zugreifen auf den Registrierungsschlüssel SYSTEM\CurrentControlSet\Services\SNMP\Parameters\TrapConfiguration ist ein Fehler aufgetreten.

Der Server "{AB8902B4-09CA-4BB6-B78D-A8F59079A8D5}" konnte innerhalb des angegebenen Zeitabschnitts mit DCOM nicht registriert werden.


Wenn es wirklich nur diese beiden sind, die sich zahlreich wiederholen, etwas anderes sehe ich über die letzten Stunden nicht, dann versuche ich mein Vorhaben aus dem vorhergehenden System daran nochmals, Rechteprobleme scheine ich diesmal keine zu haben. Ich hoffe nur, dass deswegen keine neuen entstehen, denn angefangen hat das in dem alten System mit dem Versuch, die "UimBus.sys" zu tilgen, die der Paragon Festplatten Manager 15 Professional offenbar als Enumerator in des Betriebssystems HAL registriert hatte, worüber ich unbewusst systemrelevante Verbindungen auflöste. deswegen die Dateisystemfehler. Den Paragon Festplatten Manager 15 Professional gebe ich keine Schuld, denn damit er seine Arbeit verrichten kann muss er sich in die Tiefenschicht der NTFS-Struktur registrieren, andernfalls scheitern seine Operationen - es geht halt nicht anders. Der Universal Image Mounter virtualisiert sozusagen einen Hardware-Layer, worauf die Änderungen angewendet werden und erst im NTFS-Offline-Modus, Firmware-Modus, die Plattform von dem Main-Layer entbunden und in den neuen Layer überführt wird. Hätte ich vorher gewusst, was das ist, dann hätte ich davon das Pfötchen gelassen.


Hey Ralf,
ich nutze seit Jahren kein Backup mehr - seit Windows 7 ist Windows dermaßen stabil und im Falle von Problemen intelligent, dass Backups überflüssig geworden sind, weil ersnthafte Probleme bei Sorgfalt fast Tabu sind und man sich den meisten Problemen mit einfachen Mitteln entledigen kann. Der Fall, jener mir um den Universal Image Mounters unterlaufen ist, daran bin ich selbst schuld, denn die Faulheit sich zu informieren und die daraus resultierende Unwissenheit schützt nicht vor Strafe. Aber fernab von diesem Problem, ich hatte über Jahre hinweg nichts Gravierendes mehr - letztmalig unter Windows Vista - weshalb ich mich den speicherintensiven und aufwendigen Backups entsagte.
 
An der SID ändert sich doch gar nix, der vom System verwendete Benutzername ist doch auch wurscht. Wenn man unbedingt seinen Benutzernamen bewundern will, blendet man einfach die Ordner im Explorer mit ein, schon ist das erledigt.

Dann steht der Benutzername im Excplorer als Ordner zur Verfügung.

Ich verstehe das Problem einfach nicht, das offenbar mental sein muss.
 
@areiland
Mich überrascht es nur, dass die zurückgespielten Konfigurationen von Browsern, Origin und Co. mit "knsna" kein Problem haben. Ich will mich nicht irren, doch unter Windows 7 schien das noch zu Verweisungs-Problemen geführt zu haben, es kann aber auch so sein, wie ich anfangs erläuterte, dass der für den Benutzerordner vergebene Name bloß wie auf einer Domain aufbaut, "knsna" scheint also ein Unterschlüssel zu sein, der auf einen harten String verweist, "KnSNaru", so wie es das Microsoft-Konto aus dem vorhergehenden System synchronisiert hat.

Dass "knsna" nur zufällig funktioniert glaube ich nicht, weil selbst wenn Windows 10 so intelligent ist, die Programme sind es nicht, sie suchen nach dem vollen Namen, nur ein fehlendes Zeichen bedeutet für sie einen anderen Syntax - der Ordner muss im Kern "KnSNaru" heißen, nur das sieht man von der Benutzeroberfläche ausgehend nicht.

Du bist ja was Dateisystem-Belange angeht hier der Experte, sozusagender der Haudege der alten Fachschule, vielleicht weißt Du mehr darüber, wie Windows das veranstaltet.

Hättest Du das alte System mit seinem Berechtingsproblem mithilfe der DOS-Konsole retten können - Dir von Offline die Rechte einholen können, oder war das System gänzlich zum Scheitern verurteilt?
 
Anzeige
Oben