mr.schrotti 10 Geschrieben 13. März 2014 Melden Teilen Geschrieben 13. März 2014 Hi, ich stehe grade vor genau dem selben Problem. Jedoch haben wir Windows Server 2012R2 mit einem DFS und die Clients sind alle Windows 7 Wenn User innerhalb ihrer Laufwerke oder speziell innerhalb von Abteilungslaufwerken Dateien zwischen Ordnern verschieben, bleiben die Berechtigungen von der Quelle erhalten. Meine Frage: Ist das ein Clientspezifisches verhalten, also muss der Registry Key auf dem Client angepasst werden, was bei mir nicht funktionierte bisher, auch das HotFix Paket lässt sich nicht installieren (Dieses Microsoft-Fix kann nicht aiusgeführt werden, da für den Computer ein Microsoft-Download bzw. ein Microsoft-Update erforderlich ist.) oder ist das eine Serverspezifische Einstellung? Zu Windows Server 2012 konnte ich dazu jedoch absolut nichts finden. Das verschieben innerhalb von Laufwerken durch Anwender ist IMHO kein Organisatorisches Problem sondern ein ganz normaler verwaltungstechnischer Vorgang. z.B. werden abgeschlossene Projekte in ein Archiv Ordner verschoben auf dem eben nicht mehr alle Zugriff haben. Daher sollten dort auch die Berechtigungen entfernt werden und durch die des übergeordneten Objektes ersetzt werden. Alles andere ergibt auch von der Logik her absolut keinen Sinn, jedenfalls sehe ich ihn nicht .... Zitieren Link zu diesem Kommentar
Dr.Melzer 191 Geschrieben 13. März 2014 Melden Teilen Geschrieben 13. März 2014 Es macht wenig Sinn fremde Beiträge zu kapern, vor allem Wenn sie schon über fünf Jahre alt sind. Deswegen habe ich deine Frage von dem gekaperten Thread abgetrennt. Zitieren Link zu diesem Kommentar
mr.schrotti 10 Geschrieben 13. März 2014 Autor Melden Teilen Geschrieben 13. März 2014 Hi, ok das ist immer von Forum zu Forum unterschiedlich, zumal es ja prinzipiell um das selbe Thema geht. Aber danke :) Gruß Tobias Zitieren Link zu diesem Kommentar
Daniel -MSFT- 129 Geschrieben 14. März 2014 Melden Teilen Geschrieben 14. März 2014 (bearbeitet) The MoveSecurityAttributes registry subkey is not supported in Windows 7, in Windows Vista, in Windows Server 2008 or in Windows Server 2008 R2: http://support.microsoft.com/kb/2617058 bearbeitet 14. März 2014 von Daniel -MSFT- Zitieren Link zu diesem Kommentar
mr.schrotti 10 Geschrieben 14. März 2014 Autor Melden Teilen Geschrieben 14. März 2014 (bearbeitet) Hi, den Artikel kenne ich natürlich bereits. Wie schon gesagt der Key ist auf meinem Testclient gesetzt trotz dem ändert das nichts am Move verhalten. Das MSI Paket welches ich dort runter laden kann, gibt die oben genannte Fehlermeldung zurück. Client: Windows 7 x64 Gruß Tobias edit: ich dachte unten der DL wäre der Hotfix... der Link ist aber ganz unscheinbar ganz oben. bearbeitet 14. März 2014 von mr.schrotti Zitieren Link zu diesem Kommentar
Daniel -MSFT- 129 Geschrieben 14. März 2014 Melden Teilen Geschrieben 14. März 2014 (bearbeitet) Hast Du den Wert auf 0 oder 1 gesetzt am Client? Welche Dateiversion, Datum und Größe hat denn die Shell32.dll auf den Clients? Welchen Hotfix hast Du genau heruntergeladen? Welchen Dateinamen hat der? Welche Rechte haben die Quellordner und welche die Zielordner? Hast Du Dich mit den möglichen Konsequenzen beschäftigt, denn es gibt einen guten Grund für die Standardeinstellung? bearbeitet 14. März 2014 von Daniel -MSFT- Zitieren Link zu diesem Kommentar
h-d.neuenfeldt 21 Geschrieben 14. März 2014 Melden Teilen Geschrieben 14. März 2014 @Daniel Welchen Grund meinst du ? Ich finde das bei uns auch störend, wenn der Einkaufsleiter einen Angebotsordner erstellt hat, diesen in das Verzeichnis des Sachbearbeiters VERSCHIEBT und der Sachbearbeiter dann nicht darauf zugreifen kann. Dann heißt es meist : "Sch... EDV wieso kann Kollege xy nicht mit den Daten arbeiten". Ich hätte gerne einen guten Grund warum das so ist, damit ich den Kollegen an dieser Stelle den Wind aus den Segeln nehmen kann. Zitieren Link zu diesem Kommentar
NorbertFe 2.016 Geschrieben 14. März 2014 Melden Teilen Geschrieben 14. März 2014 Musst es halt positiv verkaufen. Passiert doch oft genug "aus versehen", dann ist es immerhin geschützt und die anderen können es nicht lesen. Zitieren Link zu diesem Kommentar
h-d.neuenfeldt 21 Geschrieben 14. März 2014 Melden Teilen Geschrieben 14. März 2014 ja ja die Sindflut war auch keine Katastrophe sondern nur groß Reinemachen .... "It's a Feature not a bug" "aus Versehen " --> 50 cm Problem --> Problem ist 50 cm VOR dem Monitor Zitieren Link zu diesem Kommentar
NorbertFe 2.016 Geschrieben 14. März 2014 Melden Teilen Geschrieben 14. März 2014 (bearbeitet) Ja klar, aber wenns den Personalordner betrifft der vom Bearbeiter ausversehen verschoben würde, wäre es positiv. bearbeitet 14. März 2014 von NorbertFe Zitieren Link zu diesem Kommentar
h-d.neuenfeldt 21 Geschrieben 14. März 2014 Melden Teilen Geschrieben 14. März 2014 ich nehme die Idee einfach mal mit auf in meinen Werkzeugkasten "Kunden- und Kollegenpflege" Zitieren Link zu diesem Kommentar
Daniel -MSFT- 129 Geschrieben 15. März 2014 Melden Teilen Geschrieben 15. März 2014 (bearbeitet) Ich finde das bei uns auch störend, wenn der Einkaufsleiter einen Angebotsordner erstellt hat, diesen in das Verzeichnis des Sachbearbeiters VERSCHIEBT und der Sachbearbeiter dann nicht darauf zugreifen kann. Dann heißt es meist : "Sch... EDV wieso kann Kollege xy nicht mit den Daten arbeiten". Ich hätte gerne einen guten Grund warum das so ist, damit ich den Kollegen an dieser Stelle den Wind aus den Segeln nehmen kann. Da heißt es dann auch berechtigterweise "Sch.. EDV". Da sollten doch im Arbeitsordner für Angebote und Sachbearbeiter entsprechende Rechte gesetzt sein. Oder sollen Sachbearbeiter nicht auf den Ordner des Einkaufsleiters zugreifen können? Na dann hat das doch auch seinen guten Grund. Wenn eine Datei von einem Speicherort an einen anderen Speicherort, ob auf demselben oder einem anderen Volume kopiert wird, wird eine neue Datei im Zielordner erstellt. Die Datei erbt die Berechtigungen, die Access Control List (ACL) vom übergeordneten Ordner. Wenn eine Datei von einem Speicherort zu einem anderen auf demselben Volume verschoben wird, behält die Datei die Sicherheitsbeschreibung. Es wird nur der Zeiger auf die Ressource geändert. Wenn eine Datei von einem Speicherort zu einem anderen auf ein anderes Volume verschoben wird, dient dies ähnlich wie die Kopie, außer aus den Quellpfad die Datei gelöscht wird. Die verschobene Datei erbt die Berechtigungen vom übergeordneten Ordner. In Summe geht es auch um eine Risikoabwägung. Ein Verschieben auf der gleichen Partition erfolgt durch Ändern der Verzeichniseinträge. Da werden keine Datenblöcke angefaßt. Da dass in Sekundenbruchteilen passiert und wenn man es unbewußt macht, man den Vorgang somit kaum mitbekommt, ist es sinnvoll, dass die originalen Berechtigungen nicht verändert werden. Damit sind restriktiver konfigurierte Ordner und Daten weiterhin geschützt, auch wenn sie in unrestriktivere Ordner verschoben werden. Im Falle des Kopierens werden ja tatsächlich Daten kopiert. Das dauert dann auch dementsprechend und erfolgt in der Regel nicht unbewußt. Have fun! Daniel bearbeitet 15. März 2014 von Daniel -MSFT- Zitieren Link zu diesem Kommentar
h-d.neuenfeldt 21 Geschrieben 15. März 2014 Melden Teilen Geschrieben 15. März 2014 Hallo Daniel, unsere Struktur sieht so aus : \Einkauf \Einkauf\Vorbereitung\Projektname --> hier hat NUR der EK-Leiter Zugriff \Einkauf\Aktiv\ --> hier haben EK-Leiter und Sachbearbeiter Zugriff Wenn nun der EK-Leiter seine Daten VERSCHIEBT ergibt sich dann \Einkauf\Aktiv\Projektname --> hIer kann ohne Eingriff wiederums nur der EK-Leiter zugreifen und dieses Verhalten lässt sich mit meinem Kenntnisstand nicht ändern und aus deinen Ausführungen entnehme ich dass es sich auch nicht ändern lässt Aus diesem Grund nehme ich die Argumentation "It's a security Feature not a bug" ja auch gerne in meine Argumentationsliste auf, aber "Sch... EDV" ist da nicht das Argument... Zitieren Link zu diesem Kommentar
Daniel -MSFT- 129 Geschrieben 15. März 2014 Melden Teilen Geschrieben 15. März 2014 Nur eine Frage der Organisation. Wenn Du zum Beispiel zwei Freigaben machst und den Zugriff auf NTFS-Ebene entsprechend beschränkst: E: = \Einkauf\Aktiv\ V: = \Einkauf\Vorbereitung Wenn jetzt der EK-Leiter das vorbereitete Projekt von V: nach E: verschiebt, werden die Berechtigungen vererbt. Oder Du bringst ihm bei, beim verschieben die STRG-Taste gedrückt zu halten. Dann kopiert er den Inhalt und die Rechte werden ebenfalls vererbt. Dann muss er nur noch den Quellordner danach löschen. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.