70866
Sep 02, 2013, updated at 05:56:42 (UTC)
2212
3
0
Filesytem Phänomene in Windows 7 und 2008R2
also ich hab da ein seltsames Phänomen, und zwar auf Windows 2008R2 und auf Windows 7 auch.
Unter bestimmten Umständen erzeugen beide Betriebsystseme Anwenderspezifische Sichten auf das Betriebsystem des C-Laufwerks
Das äußert sich so, daß ein Rechner von irgendeinem User mit Administratorrechten mit der Software XY aufgespielt wird. Später spielt der "richtige" Administrator ein Update auf, und der Administrator sieht den richtigen Stand, der User den falschen Stand.
Ich dachte erst, die wollen mich veräppeln, aber ich hab das ein paarmal gecheckt auch mit einer Datei die unser Tool XY mit der Versionsnummer auf der Festplatte enthält. Und siehe da - zwei unterschiedliche Stände auf demselben Rechner.
Das ist ärgerlich und ich möchte das Problem grundlegend beseitigen, da dieses Phänomen höcsht lästig ist und die User von einer Fehlfunktion "unserser" Software ausgehen. Nur, um den Admins das auszureden brauch ich ein paar Tips - wie krieg ich diesen Zustand
a) überhaupt hin
b) wieder weg
Ich vermute daß Windows da irgendeine Art Shadowing Mechanismus benutzt, der bei bestimmten UAC Einstellungen aktiv wird.
Unter bestimmten Umständen erzeugen beide Betriebsystseme Anwenderspezifische Sichten auf das Betriebsystem des C-Laufwerks
Das äußert sich so, daß ein Rechner von irgendeinem User mit Administratorrechten mit der Software XY aufgespielt wird. Später spielt der "richtige" Administrator ein Update auf, und der Administrator sieht den richtigen Stand, der User den falschen Stand.
Ich dachte erst, die wollen mich veräppeln, aber ich hab das ein paarmal gecheckt auch mit einer Datei die unser Tool XY mit der Versionsnummer auf der Festplatte enthält. Und siehe da - zwei unterschiedliche Stände auf demselben Rechner.
Das ist ärgerlich und ich möchte das Problem grundlegend beseitigen, da dieses Phänomen höcsht lästig ist und die User von einer Fehlfunktion "unserser" Software ausgehen. Nur, um den Admins das auszureden brauch ich ein paar Tips - wie krieg ich diesen Zustand
a) überhaupt hin
b) wieder weg
Ich vermute daß Windows da irgendeine Art Shadowing Mechanismus benutzt, der bei bestimmten UAC Einstellungen aktiv wird.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 215829
Url: https://administrator.de/contentid/215829
Printed on: April 20, 2024 at 01:04 o'clock
3 Comments
Latest comment
kein Hallo auch,
dein Problem liegt sehr wahrscheinlich daran das euer Tool kein korrektes Manifest beinhaltet und die Updates dann im VirtualStore von Windows im Benutzerordner des jeweiligen Users der das Programm installiert hat landen. Landen dort Programmdateien, benutzt der jeweilige Benutzer diese, anstatt die im Programme-Ordner. Andere User sehen die neuen Dateien aber nicht, da sie ja im Benutzerordner des anderen Users liegen.
Wenn bei eurem Tool keine UAC Abfrage beim Installieren erscheint, hat der User also nicht genügend Rechte um in den Programme-Ordner zu schreiben, also landen diese im VirtualStore des Benutzers. Dieser Mechanissmus wurde unter Vista eingeführt, wegen der Kompatibilität zu älteren Setups.
Siehe dazu folgenden Beitrag: http://www.pc-magazin.de/ratgeber/profitipps-zu-windows-1210223.html
Grüße Uwe
dein Problem liegt sehr wahrscheinlich daran das euer Tool kein korrektes Manifest beinhaltet und die Updates dann im VirtualStore von Windows im Benutzerordner des jeweiligen Users der das Programm installiert hat landen. Landen dort Programmdateien, benutzt der jeweilige Benutzer diese, anstatt die im Programme-Ordner. Andere User sehen die neuen Dateien aber nicht, da sie ja im Benutzerordner des anderen Users liegen.
Wenn bei eurem Tool keine UAC Abfrage beim Installieren erscheint, hat der User also nicht genügend Rechte um in den Programme-Ordner zu schreiben, also landen diese im VirtualStore des Benutzers. Dieser Mechanissmus wurde unter Vista eingeführt, wegen der Kompatibilität zu älteren Setups.
Siehe dazu folgenden Beitrag: http://www.pc-magazin.de/ratgeber/profitipps-zu-windows-1210223.html
Grüße Uwe
danke! Klingt erstmal sehr plausibel, ich werde das prüfen wenn ich den Rechner wieder in den Fingern hab. Interessanterwiese ist der Fummel-Freak-Administrator immer noch existent, und nur der schafft es, eine von 8 VM-clones so zu "verunstalten". Ich werd die Richtlinie mal checken.....
unser Tool kannte das in der Tat (bis vor kurzem) nicht, aber wir haben in der (von mir geschriebenen) Anleitung das fett und rot geschrieben daß
a) das UAC bei der Installation auszuschalten ist
b) setup "start als Administrator" braucht bzw. bei geskripteten Installation ein Runas benötigt wird.
Leider liefern wir für die Software keine Koffeintabletten und keinen Administrator-Taser aus, der ihn auch den ganzen Tag lang wach hält. Daß ausgerechnet in eigetlich gemanagten Umgebungen, in der eine Vielzahl von Clones aus einem funktionierenden Original gefertigt werden, immer wieder einzelne Rechner eine kaputte Konfiguration haben, dürfte wohl darauf zurückzuführen sein, daß am regulären Wartungsprozeß vorbei unautorisierte Zugriffe stattgefunden haben - und das ist kein Einzelfall,.....
unser Tool kannte das in der Tat (bis vor kurzem) nicht, aber wir haben in der (von mir geschriebenen) Anleitung das fett und rot geschrieben daß
a) das UAC bei der Installation auszuschalten ist
b) setup "start als Administrator" braucht bzw. bei geskripteten Installation ein Runas benötigt wird.
Leider liefern wir für die Software keine Koffeintabletten und keinen Administrator-Taser aus, der ihn auch den ganzen Tag lang wach hält. Daß ausgerechnet in eigetlich gemanagten Umgebungen, in der eine Vielzahl von Clones aus einem funktionierenden Original gefertigt werden, immer wieder einzelne Rechner eine kaputte Konfiguration haben, dürfte wohl darauf zurückzuführen sein, daß am regulären Wartungsprozeß vorbei unautorisierte Zugriffe stattgefunden haben - und das ist kein Einzelfall,.....
so Problem gekärt - es gab in der Tat einen virtualstore.
Ist aber versteckt, aber das auszuschalten ist keine Heldentat.... %localappdata% fördert dann ein Verzeichnis namens Virtualstore zutage indem dann Teile von unsrem Tool drinwaren.
Es gibt 2 verschiedene Abhilfen dafür:
- Der User deinstalliert den Kram mit seinem Account, der "echte" lokale Administrator installiert es dann erneut.
- Der Admin killt den Kram durch Löschen des Virtualstore Verzeichnisses und installiert mit "als Administrator" ausführen.....
Grundlegend sollte aber die Richtlinie "Zugriffsfehler auf Registry und Filesysteme virtualliseiren" aber abgestellt sein. Die Richtlinie mag zwar auf lokalen Workstations Sinn machen, aber keinstenfallls auf Terminalservern oder gar einem Master für eine VDI Lösung und noch weniger auf den Clones davon.
Ist aber versteckt, aber das auszuschalten ist keine Heldentat.... %localappdata% fördert dann ein Verzeichnis namens Virtualstore zutage indem dann Teile von unsrem Tool drinwaren.
Es gibt 2 verschiedene Abhilfen dafür:
- Der User deinstalliert den Kram mit seinem Account, der "echte" lokale Administrator installiert es dann erneut.
- Der Admin killt den Kram durch Löschen des Virtualstore Verzeichnisses und installiert mit "als Administrator" ausführen.....
Grundlegend sollte aber die Richtlinie "Zugriffsfehler auf Registry und Filesysteme virtualliseiren" aber abgestellt sein. Die Richtlinie mag zwar auf lokalen Workstations Sinn machen, aber keinstenfallls auf Terminalservern oder gar einem Master für eine VDI Lösung und noch weniger auf den Clones davon.
