ziemlich frisch auf diesem Gebiet, deswegen hab ich mich erstmal in Ruhe angeschaut, was alles von vorherein auf dem Server (hier SBS2003) so "rumliegt".
Dabei ist mir aufgefallen, daß eine Kontosperrungsrichtlinie irgendwie mehrfach vorkommt. Zum einen in der Default Policy, die deckungsgleich mit "Verwaltung -> Sicherheitsrichtlinie für Domänen" (ja, ist sie das?) ist, zum einen gibt es noch Small Business Server-Kontosperrungsrichtlinie in der Gruppenrichtlinienverwaltung. Da dieses die Standardeinstellungen zu sein scheinen, frage ich mich, warum es noch mal eine einzelne gibt (die wohl die entscheidene ist, wenn ich dad mit der Reihenfolge richtig verstanden hab)?
Desweitern lese ich immer, man solle die Finger weg von der Defaultrichtlinie lassen. Warum eigentlich?
Und dann wüßt ich gern noch, wie es sich mit dem Zeitfaktor verhält, in der ein Client Richtlinie(n) verarbeitet. Besser eine "große", mit vielen unterschiedlichen Einstellungen, oder mehrere unterschiedliche "kleine", deren Namen einem schon etwas über den Inhalt aussagt. (Explorer-Richtlinie, Desktop-Richtlinie,...)
Dabei ist mir aufgefallen, daß eine Kontosperrungsrichtlinie irgendwie mehrfach vorkommt.
Jupp.
Zum einen in der Default Policy, die deckungsgleich mit "Verwaltung -> Sicherheitsrichtlinie für Domänen" (ja, ist sie das?)
Ja das ist das gleiche was du da siehst.
ist, zum einen gibt es noch Small Business Server-Kontosperrungsrichtlinie in der Gruppenrichtlinienverwaltung. Da dieses die Standardeinstellungen zu sein scheinen, frage ich mich, warum es noch mal eine einzelne gibt (die wohl die entscheidene ist, wenn ich dad mit der Reihenfolge richtig verstanden hab)?
weil das SBS Team dachte, dass es praktischer zu handhaben ist für wenig erfahrene Admins. Die Kennwortrichtlinie des SBS hat dabei eine höhere Priorität (siehst du in der GPMC) und deswegen gelten deren Einstellungen und nicht die der Default Domain Policy.
Desweitern lese ich immer, man solle die Finger weg von der Defaultrichtlinie lassen. Warum eigentlich?
Weil die Richtlinie für alle Objekte in deiner Domain gilt und dabei auch mal was Unerwünschtes bei rauskommen kann. Ausserdem werden bspw. die Exchange 200x Berechtigungen in der Default Domain Policy gesetzt, so dass du damit im Zweifel auch andere Systeme zum Stehen bringen kannst. Wenn du weißt was du tust, kannst du natürlich die DDP auch bearbeiten.
Und dann wüßt ich gern noch, wie es sich mit dem Zeitfaktor verhält, in der ein Client Richtlinie(n) verarbeitet. Besser eine "große", mit vielen unterschiedlichen Einstellungen, oder mehrere unterschiedliche "kleine", deren Namen einem schon etwas über den Inhalt aussagt. (Explorer-Richtlinie, Desktop-Richtlinie,...)
Was hat die Aufteilung der einzelnen Policies in GPOs mit dem Zeitfaktor zu tun? Oder meinst du die Übernahmegeschwindigkeit?
das ist genau das, was ich wissen wollte. zum letzten Punkt: Ja, ich meine die Übernahmegeschwindigkeit, also die Zeit, die die Clients zum Abarbeiten beim Sytemstart benötigen.
das ist genau das, was ich wissen wollte. zum letzten Punkt: Ja, ich meine die Übernahmegeschwindigkeit, also die Zeit, die die Clients zum Abarbeiten beim Sytemstart benötigen.
Dank + Gruß
idephili
Versuchs einfach mal. Aber ich denke das wird sich eher im nicht feststellbaren Bereich befinden.
Desweitern lese ich immer, man solle die Finger weg von der Defaultrichtlinie lassen. Warum eigentlich?
Und dann wüßt ich gern noch, wie es sich mit dem Zeitfaktor verhält, in der ein Client Richtlinie(n) verarbeitet. Besser eine "große", mit vielen unterschiedlichen Einstellungen, oder mehrere unterschiedliche "kleine", deren Namen einem schon etwas über den Inhalt aussagt. (Explorer-Richtlinie, Desktop-Richtlinie,...)
Hallo idephili,
zur Defaultrichtlinie:
Wenn du bei MS einen Supportcall aufmachst und der Support-Engineer entdeckt, dass die Default-GPOs verändert wurden, bist du solange Out-Of-Support, bis du den ursprünglichen Zustand der DefaultGPOs wiederhergestellt hast (gibts Tools dazu). Von daher, diese GPOs lieber gar nicht verändern, zumal es kein Problem ist, mit eigenen GPOs die gewünschten Werte zu verändern.
zur Zeit: Wenn du es selbst austesten möchstest, eignet sich eine spezielle Logdatei dazu, die du mit dem Key userenvdebuglevel (value 10002) aktivieren kannst. How to enable user environment debug logging in retail builds of Windows
Zur Auswertung des relativ unübersichtlichen Logs kannst den kostenlosen Policyreporter von Syspro nutzen. Damit bekommst du die Zeiten auf die Millisekunde raus SysPro Software -> Policy Reporter
Ich hatte die Frage auch schonmal an den MS-Support gestellt und auch selbst untersucht. Das Ergebnis war, dass die Dauer für das Abarbeiten der Policies so oder so die Gesamtanmeldedauer am Client (Terminalserver) kaum beeinflusst. Ich hatte ca. 1 min bis 1:30 Anmeldedauer, davon warens nur wenige Sekunden für die Policies.
Wenn du bei MS einen Supportcall aufmachst und der Support-Engineer entdeckt, dass die Default-GPOs verändert wurden, bist du solange Out-Of-Support, bis du den ursprünglichen Zustand der DefaultGPOs wiederhergestellt hast (gibts Tools dazu).
Ist mir neu. Steht das irgendwo, oder war das die Aussage des MS Engineers?
Wenn du bei MS einen Supportcall aufmachst und der Support-Engineer entdeckt, dass die Default-GPOs verändert wurden, bist du solange Out-Of-Support, bis du den ursprünglichen Zustand der DefaultGPOs wiederhergestellt hast (gibts Tools dazu).
Wenn dem grundsätzlich so ist, dann ist das eine weitere, sehr gute Begründung, die Default Policies nicht anzufassen ...
Die Aussage stammt von unseren MicrosoftConsultants.
Wenn's mal richtig z.B. im AD klemmt, kann der MS-Support verlangen, von allen GPOs bis auf die Default-GPOs die Verlinkung zu entfernen , um nur mit diesen Default-GPOs die Funktionsfähigkeit z.B. des ADs zu überprüfen. Der Test hat natürlich nur bei unveränderten DGPOS eine Aussagekraft.
Die Aussage stammt von unseren MicrosoftConsultants.
Wenn's mal richtig z.B. im AD klemmt, kann der MS-Support verlangen, von allen GPOs bis auf die Default-GPOs die Verlinkung zu entfernen , um nur mit diesen Default-GPOs die Funktionsfähigkeit z.B. des ADs zu überprüfen. Der Test hat natürlich nur bei unveränderten DGPOS eine Aussagekraft.
cu
blub
Hmm naja. Also so eine Aussage ist definitiv dann aber auch kein offizielles MS Statement würde ich sagen.
Hmm naja. Also so eine Aussage ist definitiv dann aber auch kein offizielles MS Statement würde ich sagen.
Es war zumindest eine m.E. sinnvolle Anmerkung bei einem offiziellen DesignReview von MS. Ob diese Aussage hochoffiziell aus Redmond stammte, interessiert mich nicht so stark, um deswegen bei MS nochmal nachzufragen. Soll halt jeder mit den Default-GPOs halten, wie er meint...
Unabhängig davon, ist man bei MS recht schnell "out-of-support", wenn man Defaulteinstellungen verändert
