daabm

Ne, so machst Du das nicht. Schau mal hier: https://evilgpo.blogspot.com/2015/04/wer-bin-ich-und-was-darf-ich.html Wir setzen das grad im RZ-Betrieb um und es funktioniert prima. Wenn man die OU-Namen passend zu den Namen der administrativen Gruppen wählt und die Server sich immer direkt in ihrer "Anwendungs-OU" befinden, kann man das sogar mit einer einzigen Preference erschlagen Kurz zusammengefaßt: Finger weg von Restricted Groups, und Finger weg von direktem Zuweisen von Benutzerrechten zu AD-Gruppen. Immer eine lokale Gruppe erstellen und berechtigen und die dann mit den AD-Gruppen nach Bedarf füllen. 2 Ausnahmen: Lokale Admins (klar) und Remote Desktop Users - da funktioniert es warum auch immer nicht, da muß tatsächlich die Standardgruppe Remote Desktop Users verwendet werden.

Nein. Die Skript-CSE schreibt nur die Skripts aus GPOs in die Registry, ausgeführt werden sie immer als letztes. Als Lösung würde ich vorschlagen: Erstelle 4 Preferences. 1 und 2 löschen beide Drucker, 3 und 4 erstellen mit ILT den korrekten neu.

Aufpassen, daß es nicht zu kompliziert wird, sonst scheiterst Du an der Akzeptanz... Ein Anwendungs-Admin braucht auf den zugehörigen Servern nur RDP/Interactive, da braucht es keinen extra User. Und wenn da nur die eine Anwendung läuft, dann schadet lokaler Admin auch nicht wirklich. Wenn die Anwendung nicht ohnehin remote zu administrieren ist.

Jo, man vermeide in Servern alles, was mehr als MLC hat - und auch das halte ich persönlich schon für grenzwertig Wenn ich dran denke, daß die inzwischen QLC bauen, da sind 16x so viele Bitfehler systemimmanent...

In depth: XPerf. In short: Group Policy Eventlog, ggf. mit gplogview - da steht schon ziemlich viel drin über Zeiten.

Zu 1: Möglicherweise läßt sich das nicht als Standardeinstellung festlegen - wäre für mich logisch. Zu 2: Anderer Mechanismus, gleiches Ergebnis. Beide Mechanismen taugen nix - für Drucker und Laufwerke sind gute Skripts die mit Abstand beste Lösung.

Löschen und neu anlegen geht natürlich auch, finde ich aber vergleichsweise aufwändig

Bei User-GPOs braucht der Computer nur Lesen, ob Du dem Apply verweigerst oder nicht ist herzlich egal. Du mußt dem einen Computer also explizit das Lesen verweigern.

Ich werfe mal noch spaßeshalber Symlinks und Junctions mit in den Ring Der Explorer folgt diesen NICHT.

Der TO ist doch schon längst wieder weg. Der will doch nur mehrfache Sessions für den gleichen User - was sonst niemand will.

Ja, tut man Ist echt Grütze, daß Microsoft das bei den meisten MMC-Snapins selber auch verkackt hat. dsa, domain, dssite, gpmc - alle brauchen normalerweise keine Admin-Rechte, wenn die nur ein delegierter User benutzen soll. Okay, bei domain und dssite evtl doch

Ich verstehe es nicht. Der User ist in einer Gruppe, die lokal Admin wird, soweit ok. Was meinst Du jetzt mit "als anderer Benutzer"? Als welcher andere Benutzer?

Nee, Norbert - steh zu Deinen Schwächen und Stärken, wie ich auch. Ich kann nur AD und hab von XCH keine Ahnung, ich kenn nur das blöde ProxyAdresses-Attribut mit seiner Groß- und Kleinschreibung (wenn das überhaupt noch so ist...).

Vielleicht ist das in dem Fall dann auch besser so

Warum auf dem DC? Und warum in einer Admin-Commandline? Beides nicht erforderlich zum Auslesen von SPNs

Sollte kein Problem sein - wenn der angemeldete User kein Admin ist und Du an den Standardrechten nichts gedreht hast, kommt er an das Kennwort nicht ran. Und wenn er auch die Dateien nicht ändern kann, die der Task ausführt, ist alles ok. Interessehalber: Wie startet man eine XML-Datei? SCNR...

Oha, der Chef ist heute sehr milde :-)))

Und wenn es nur um die Wiederherstellung geht: Nicht lachen - "GPMC sample scripts", CreateXMLfromEnvironment und CreateEnvironmentFromXML. Legt sogar Gruppen und User ggf. an...

SPN = Service Principal Name. setspn -?

>bin müde, das raff ich jetzt doch nimmer. Und morgen kriegen wir eh nen Anschiß wegen OT...

War kein Vorwurf - ich kenn das Problem.... "Der Server ist doch da, kann das da nicht noch mit drauf"

Bäh...

Naja, dann weißt Du ja sicher auch: Ein DC ist ein DC - und sonst nichts. Und spezielle Verwaltungstools haben da ohnehin nichts zu suchen.

Jetzt habt Ihr den TO vmtl komplett überfordert

Da wären wir wieder bei ProfileList - mit Dir ist fachlich echt immer nice, da habe ich nie das Gefühl, noch was erklären zu müssen