GPO zieht für Domainadmin trotz Securityfiltering?

[guybrush 19]

Hallo Kollegen,

 

seit einiger Zeit fällt mir auf, dass GPOs, die ich am DC erstelle und mit "gpupdate /force" quasi aktiviere, auch für den am DC angemeldeten Domainadmin ziehen?

Konkret geht´s derzeit um mein Druckerdeployment. Ich erstelle eine GPP, in der ein Drucker einer gewissen Benutzergruppe zugewiesen wird. beim Securityfilter hab ich die Authenticated User entfernt und die gewünschte Gruppe hinzugefügt. Läuft auch alles soweit recht ordentlich, aber eben beim gpupdate will er den DA am DC abmelden?

Das war früher nicht so, da bin ich mir ganz sicher. Ich wüsste aber auch nicht, was ich da anders machen würde als sonst?

 

Vielleicht hat da jemand einen Tip für mich. Der Drucker wird am DC (zum Glück) nicht erstellt, es gibt auch im Eventlog keinen Eintrag (ist wirklich Blütenweiß).

 

LG

Johannes

[Sunny61 773]

seit einiger Zeit fällt mir auf, dass GPOs, die ich am DC erstelle und mit "gpupdate /force" quasi aktiviere, auch für den am DC angemeldeten Domainadmin ziehen?

 

Das /force ist in diesem Fall flüssiger als Wasser. Außerdem bewirkt das eben nur, dass die GPO direkt auf dem Server vollständig neu gezogen wird. Das willst Du vermutlich gar nicht. Eine Zwangsverteilung kannst Du damit nicht erreichen. Das geht nur vom Client aus. Aber auch da hilft ein /force fast nie.

 

Konkret geht´s derzeit um mein Druckerdeployment. Ich erstelle eine GPP, in der ein Drucker einer gewissen Benutzergruppe zugewiesen wird. beim Securityfilter hab ich die Authenticated User entfernt und die gewünschte Gruppe hinzugefügt. Läuft auch alles soweit recht ordentlich, aber eben beim gpupdate will er den DA am DC abmelden?

 

Na klar will er abmelden, Du hast ja ein gpupdate /force eingetippt. Woher soll der Befehl denn wissen, dass Du nur ein Deployment für Benutzer durchgeführt hast?

 

Das war früher nicht so, da bin ich mir ganz sicher. Ich wüsste aber auch nicht, was ich da anders machen würde als sonst?

 

Mit /force wird eben auch die Benutzer GPO vollständig neu geholt, dazu ist ein ab- und wieder anmelden nötig. Vollkommen normal die Aufforderung also.

 

Vielleicht hat da jemand einen Tip für mich. Der Drucker wird am DC (zum Glück) nicht erstellt, es gibt auch im Eventlog keinen Eintrag (ist wirklich Blütenweiß).

 

Das ist schon alles in Ordnung, bis auf dein gpupdate /force. Das brauchst Du nicht am DC zu machen, ausser Du willst das der DC und der am DC angemeldete Benutzer schnellstens die GPOs vollständig neu abholen und einlesen. Wenn die Benutzer die Drucker schnellstens bekommen sollen, mußt Du eine Replizierung zwischen den DCs anschieben und die Benutzer anschließend zum ab- und wieder anmelden auffordern.

[NilsK 2.795]

Moin,

 

Na klar will er abmelden, Du hast ja ein gpupdate /force eingetippt.[/Quote]

 

ich kann dir gerade nicht ganz folgen. In den vergangenen dreizehn Jahren hat gpupdate /force (bzw. dessen Vorgänger secedit, nur um vorzubeugen ;)) noch nie dazu geführt, dass ich zur Abmeldung aufgefordert wurde. Reden wir jetzt gerade aneinander vorbei, übersehe ich was, oder hast du dich vertan?

 

Gruß, Nils

[Sunny61 773]

ich kann dir gerade nicht ganz folgen. In den vergangenen dreizehn Jahren hat gpupdate /force (bzw. dessen Vorgänger secedit, nur um vorzubeugen ;)) noch nie dazu geführt, dass ich zur Abmeldung aufgefordert wurde. Reden wir jetzt gerade aneinander vorbei, übersehe ich was, oder hast du dich vertan?

 

Ich kenne das ab- und wieder anmelden bei gpupdate /force seit mind. ein oder zwei Jahren. Genauer weiß ich es leider nicht, da es für mich in diesem Zusammenhang selbstverständlich geworden ist.

[olc 18]

Hi,

 

das "/force" kann in einigen Situationen zur Abmeldung oder zum Neustart des Rechners auffordern bzw. danach fragen.

 

Hintergrund: Bestimmte CSEs werden nur synchron verarbeitet - und um in diesen synchronen Modus zu kommen, muß eine Anmeldung bzw. bei Computereinstellungen ein Neustart her.

 

Das "/force" erzwingt ein erneutes Anwenden von diesen Einstellungen und weist dann darauf hin, daß die Einstellungen erst nach der Anmeldung / dem Neustart gezogen werden können.

 

Haben Benutzer also eine oder mehrere dieser CSEs aktiviert (Beispiel "Folder Redirection") oder sind für Computer (Gott bewahre ;) ) Softwareverteilungen per GPO aktiv, kann es zu der Meldung in der CMD kommen.

 

GPP Netzlaufwerke zählen meines Wissens auch dazu, bei den Druckern bin ich mir nicht sicher.

 

Viele Grüße

olc

[NilsK 2.795]

Moin,

 

das "/force" kann in einigen Situationen zur Abmeldung oder zum Neustart des Rechners auffordern bzw. danach fragen.

 

schau an, das war mir neu. Jaja, ist schon lohnenswert, ab und an ins Board zu schauen. :D

 

Gruß, Nils

[guybrush 19]

Naja, um ehrlich zu sein, das /force mach ich eigentlich nur aus rein (subjektiv) psychologischen Gründen.

Da werden dann ja einfach alle Gruppenrichtlinien verarbeitet, gleich ob sich was geändert hat oder nicht, und die Replikation zu den anderen Domaincontrollern wird angestoßen (?). Zumindest meine Meinung bisher.

 

Ich habe bisher auch schon viele Benutzerbezogene Gruppenrichtlinien erstellt, diverse Ordnerumleitungen, Laufwerksmappings, Dateioperationen usw... - und immer mit dem Securityfilter auf die Usergruppe. Dann zum testen am DC gpupdate /force, danach am Terminalserver, und danach anmelden und schauen, ob die GP auch greift.

 

Da hat es im Domainadmin, unter dem ich sowas am DC immer mache, noch nie ein Logoff gebraucht. Erst kürzlich ist mir das aufgefallen...

[NilsK 2.795]

Moin,

 

aus rein (subjektiv) psychologischen Gründen. [/Quote]

 

das dürfte der Punkt sein. ;) Durch die Namensgebung hat Microsoft das auch nahegelegt, force klingt so schön martialisch.

 

und die Replikation zu den anderen Domaincontrollern wird angestoßen (?).

 

Nö. Das ist eine rein clientseitige Sache.

 

Da hat es im Domainadmin, unter dem ich sowas am DC immer mache, noch nie ein Logoff gebraucht. Erst kürzlich ist mir das aufgefallen...

 

Hab ich, wie gesagt, auch noch nie gesehen.

 

Gruß, Nils

[olc 18]

Hi,

 

Welche Einstellungen bzw. welche CSEs werden denn aktuell für den Benutzer angewendet?

Ab Vista sollte auch im Ereignisprotokoll (Group Policy) stehen, welche CSE die Neuanmeldung notwendig werden lässt, wenn ich mich recht entsinne.

 

Viele Grüße

olc

[guybrush 19]

In meinem Fall ist es um Druckermappings (im Replacemodus) gegangen. Eingehend wollte ich es via Item Level Targeting auf die Abteilungsgruppen runterbrechen. Habs dann aber via Sicherheitsfilter gelöst, weil es für ersteres einen Patch brauchte, der mir beim Testen schon Probleme gemacht hat.

 

Die Druckermappings, gleich wie Sharemappings erfolgen beim Anmelden, deshalb fragt er danach (meiner Erfahrung nach).

 

LG

[olc 18]

Hi,

 

Lösch einmal das GPP History Verzeichnis :The caveats of using Group Policy Preferences on Terminal Servers - AD Troubleshooting - Site Home - TechNet Blogs

 

P. S. : GPOs auf einem DC zu "testen" ist wirklich suboptimal... ;)

 

Viele Grüße

olc

[guybrush 19]

P. S. : GPOs auf einem DC zu "testen" ist wirklich suboptimal... ;)

 

Das hast du glaub ich falsch verstanden - ich erstelle sie nur am DC. Getestet wird natürlich auf einem Client. So viel Respekt vor meiner internen Reputation und vor meinem Feierabend hab ich schon, dass ich solche Dinge nicht auf einem DC teste ;)

 

Nö. Das ist eine rein clientseitige Sache.

 

Am Client mach ich es ebenfalls. Das Kommando am DC abzusetzen ist einfach nur aus alten 2k-Zeiten noch tief drinnen (damals halt mit secedit, aber ich habs mir damals schon vielleicht falsch angewöhnt - zumindest schadets nicht). Weisst eh, wie es mit Gewohnheiten so sein kann....

 

@olc:

Habe mir deinen Link durchgelesen, aber so ganz sicher bin ich mir nicht, worauf du hinaus willst? Die GPP wird zwar später auch am TS ausgeführt werden, sobald ich meine User migriert habe. Oder geht´s da gar nicht um den TS, sondern einfach darum, den Ordner am DC zu leeren?

 

LG

[olc 18]

Hi,

 

also noch einmal der Reihe nach:

 

1. Du erstellst eine GPO auf einem DC. Hinweis dazu: Das ist auch nicht optimal - besser einen administrativen TS verwenden. Am DC muß man sich in der Regel nicht anmelden.

 

2. Du führst auf dem DC ein "gpupdate /force" aus. Das ist zwar unnötig, aber Du machst es dennoch. ;)

 

3. Nun sollst Du seit neuestem vom DC abgemeldet werden, obwohl die GPO dort gar nicht greifen sollte. Korrekt?

 

Nun meine Annahme:

 

Du hast die Richtlinie wie oben beschrieben erst verlinkt, dann per Item-Level Targeting jedoch eingeschränkt. Ab diesem Moment wird auch auf dem DC eine GPP History angelegt - sofern die entsprechende GPO / GPP zu diesem zeitpunkt für den Admin oder den DC freigegeben war.

 

Später hast Du dann die Sicherheitsfilterung auf GPO Basis verwendet, so daß die Richtlinie weder für den Benutzer noch für den DC greifen dürfte.

Jedoch war zu diesem Zeitpunkt schon einmal die GPP mit Item-Level Targeting auf dem DC "angewendet" - somit bleibt die GPP History bestehen.

 

Der Link von mir oben zeigt den Speicherort der GPP History - diese solltest Du testweise auf dem DC einmal löschen und prüfen, ob es danach weiterhin zu der Aufforderung kommt, den Benutzer abzumelden.

 

Viele Grüße

olc

[Sunny61 773]

Naja, um ehrlich zu sein, das /force mach ich eigentlich nur aus rein (subjektiv) psychologischen Gründen.

Da werden dann ja einfach alle Gruppenrichtlinien verarbeitet, gleich ob sich was geändert hat oder nicht, und die Replikation zu den anderen Domaincontrollern wird angestoßen (?). Zumindest meine Meinung bisher.

 

Es werden in diesem deinen Fall aber nur die GPOs für den DC erneut angewendet. Den/die Clients juckt das gar nicht, die bekommen nichts mit davon.

 

Und eine Replikation zu anderen DCs wird auch nicht angeschoben.

 

Ich habe bisher auch schon viele Benutzerbezogene Gruppenrichtlinien erstellt, diverse Ordnerumleitungen, Laufwerksmappings, Dateioperationen usw... - und immer mit dem Securityfilter auf die Usergruppe. Dann zum testen am DC gpupdate /force, danach am Terminalserver, und danach anmelden und schauen, ob die GP auch greift.

 

Benutzerrichtlinien testet man nicht am DC, entweder an einem Testclient oder am TS mit einem Testbenutzerkonto. Die können am DC gar nicht greifen.