wbs2008 10 Geschrieben 13. März 2009 Melden Teilen Geschrieben 13. März 2009 Guten Tag, ich bin zur Zeit auf der Suche nach einer Möglichkeit, die Registerkarte Vorherige Versionen der Schattenkopien bei nicht Admins auszublenden. Ich hab natürlich die Möglichkeit gefunden, die Registry entsprechend anzupassen, aber das ist, nur dann was, wenn es nicht anders lösbar ist. Das nächste war, das ich hier einen Thread gefunden hatte, welcher sicher auch mit dem Thema beschäftigt und welcher Versuchsweise angab, man könnte probieren dies über die Softwareeinschränkungsrichtline des AD zu machen. Ich habe das ganze jetzt mal in einer Testumgebung versucht, entweder sind meine VMs hinüber, was ich fast vermute weil ein gpresult auf dem Client die Antwort gibt, es gäbe kein Gruppenrichtlinienobjekt beim ermitteln der SSID oder das funktioniert so nicht. Mich würde mal interessieren, ob das schon mal jemand auf diese Art versucht hat und wie die Ergebnisse sind. Weil dadurch könnte ich ja dynamisch entscheiden, auf Basis einer Gruppe, wer diese Karte angezeigt bekommt und wer nicht. Danke Euch... Zitieren Link zu diesem Kommentar
Dukel 457 Geschrieben 13. März 2009 Melden Teilen Geschrieben 13. März 2009 Müssen auf den gleichen Rechnern die Admins die Shattenkopien sehen dürfen und Anwender nicht? Wenn nein, könnte man einfach den Schattenkopien Client bei den Anwendern weg lassen. Zitieren Link zu diesem Kommentar
wbs2008 10 Geschrieben 13. März 2009 Autor Melden Teilen Geschrieben 13. März 2009 Ich will verhindern, das ich den Schattenkopienclient auf dem Rechner deinstalliere... Falls ich ihn dann doch mal brauche. Es gäb natürlich noch die Überlegung, das File direkt auf den Rechnern anders zu berechtigen, aber das wäre dann wieder an die Maschinengebunden. Wenn ich es hinkriegen kann, würde ich das schon gerne auf diese Art und Weise probieren, deshalb ob es da Erfahrungen gibt... Ich werde das mal mit leeren VMs also frischen testen. Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 13. März 2009 Melden Teilen Geschrieben 13. März 2009 Hi, Du kannst per GPO die NTFS Berechtigungen auf die Datei TWEXT.DLL normalen Benutzern verweigern. Du nutzt dafür keine Software Restriction Policy, sondern eine Policy, in der Du NTFS ACLs auf die Datei vergibst und den entsprechenden Benutzern die Berechtigungen entziehst (bzw. besser gesagt Vollzugriff verweigerst). Die entsprechenden Einstellungen findest Du im "Windows Settings" --> "Security" Zweig einer Policy. Viele Grüße olc Zitieren Link zu diesem Kommentar
wbs2008 10 Geschrieben 16. März 2009 Autor Melden Teilen Geschrieben 16. März 2009 Hallo zusammen, OLC, danke für den Tipp... Ich habe das ganze einmal ausprobiert, das scheint ja nur eine "pro Computer" Richtlinie zu sein. Ich habe also unter dem Punkt "Dateisystem" das ganze eingepflegt. Mit den entsprechenden Berechtigungen. Allerdings habe ich hier das twext.dll File nur vom Server wählen können. Als komplette Ausgabe hat er am Ende ein %systemroot%\system32\twext.dll gemacht. Da liegt natürlich auch das File auf den Clients. Allerdings wurde diese Richtlinie nicht auf die Clients angewendet, sondern hat die Berechtigungen der Datei auf dem Server geändert. :suspect: Das war so im Grunde aber nicht gedacht, diese Berechtigung sollte eigentlich auf die Datei auf den Clients übernommen werden. Hat das evtl. damit zutun, das ich die Datei auf dem Server ausgewählt habe? Wenn man mal so im Netz schaut muss ja diese Option Dateisystem schon die richtige sein um Files auf den Clients anders zu berechtigen. Hat da jemand einen Tipp oder einen Vorschlag? Zitieren Link zu diesem Kommentar
BrainStorm 10 Geschrieben 16. März 2009 Melden Teilen Geschrieben 16. März 2009 Hallo wbs2008, hast du die Richtlinie auch mit der OU in der die Zielcomputerkonten (Clients) liegen verknüpft? Zitieren Link zu diesem Kommentar
wbs2008 10 Geschrieben 16. März 2009 Autor Melden Teilen Geschrieben 16. März 2009 Hallo BrainStorm, danke für Deine Antwort. Ja, das habe ich natürlich gemacht. :) Zitieren Link zu diesem Kommentar
NorbertFe 2.114 Geschrieben 16. März 2009 Melden Teilen Geschrieben 16. März 2009 Nein, das geht auch pro User. Ab Vista war es per DEfault mit dabei im gpeditor. Bei W2k3 mußte man sich das noch selbst bauen. Weiter unten mal einige Sample´s und Codebeispiele: Nr. 31. (Nicht vom Titel irritieren lasse ;)) HTH Norbert Zitieren Link zu diesem Kommentar
wbs2008 10 Geschrieben 16. März 2009 Autor Melden Teilen Geschrieben 16. März 2009 Hallo, danke Norbert für den Tipp... Das von dir vorgeschlagene Template, ist das eines der Templates dessen Einstellung nicht wieder durch Löschen der Richtlinie rückgängig gemacht wird? Auf der Seite wurde ja gewarnt, das die meisten Templates eben nicht konform sind zu W2K3. Aber trotzdem Danke Danke Danke. Was mir noch aufgefallen ist, unter den Einstellungen zum Dateisystem in den Policys... Da kann man nur Dateien auswählen, welche auch auf dem Server vorhanden sind, z.B. Systemdateien. Angenommen ich wollte jetzt ein File auf C:\ auf den Clients dementsprechend Berechtigungsmäßig anpassen. Nur als Beispiel halt. Müsste ich dann eine "fake" Datei erstellen oder ist dieser Prozess nur auf Systemdateien ausgelegt? Zitieren Link zu diesem Kommentar
NorbertFe 2.114 Geschrieben 16. März 2009 Melden Teilen Geschrieben 16. März 2009 Hallo, danke Norbert für den Tipp... Das von dir vorgeschlagene Template, ist das eines der Templates dessen Einstellung nicht wieder durch Löschen der Richtlinie rückgängig gemacht wird? Auf der Seite wurde ja gewarnt, das die meisten Templates eben nicht konform sind zu W2K3. Na und? Was spricht deinerseits gegen einen kurzen Test mit einem TESTUSER? ;) Was mir noch aufgefallen ist, unter den Einstellungen zum Dateisystem in den Policys... Da kann man nur Dateien auswählen, welche auch auf dem Server vorhanden sind, z.B. Systemdateien. Dann installier die GPMC halt auf einem Client. Bye Norbert 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.