btodar
Goto Top

Probleme bei GPO Übernahme

Hallo zusammen,

ich habe bei folgendem Szenario ein Problem:

Wir haben unseren Domänencontroller von 2003 per InPlaceUpdate auf 2008 aktualisiert. Soweit keine Probleme!

Jetzt möchten wir Proxyeinstellungen per GPO verteilen. Also neue GPO erstellt mit den nötigen Einstellungen und mit der Domäne verknüpft.

Wir haben als Clients XP, Vista und Windows 7. Lokale Richtlinien gibt es bei uns nicht.

Wenn ich mich nun als odinärer User an einem Client anmelde, bekomme ich die Settings!

Jetzt zu meinem Problem:

Wenn ich die Proxyeinstellungen manuell ändere, bekomme ich die Einstellungen nicht mehr von der GPO überschrieben.
Weiß jemand, warum das so ist oder wie ich es erreiche, dass IMMER die GPO ziehen soll.

MfG BtodaR

Content-ID: 127999

Url: https://administrator.de/forum/probleme-bei-gpo-uebernahme-127999.html

Ausgedruckt am: 23.12.2024 um 01:12 Uhr

RedRabbit
RedRabbit 27.10.2009 um 10:50:10 Uhr
Goto Top
Ich kenn die Situation jetzt nur von 2003 aus der Firma, wir haben ein ähnliches Problem gehabt, ist aber im Prinzip dasselbe.

Gibt 2 Möglichkeiten:
1. Per lokaler Sicherheitsrichtlinie allen Benutzern den Zugriff auf Proxsyeinstellungen sperren und die Proxyeinstellungen dann per GPO festlegen. Diese Variante hat den Nachteil, daß man auch als Admin erst die lokale Sicherheitsrichtlinie umbauen muss, um an die Proxyeinstellungen zu kommen, wenn man mal was testen will. Dafür hat sie den Vorteil, daß lokale Anmeldungen auch keinen Zugriff auf die Proxyeinstellungen haben und somit deinen Proxy nicht umgehen können. So haben wir es in der Firma geregelt.
(Computer-adminvorlagen-Windowskomponenten-Internetsystemsteuerung-VERBINDUNGSSEITE DEAKTIVIEREN) oder (Computer-adminvorlagen-Windowskomponenten-Internet Explorer-Änderung der Proxyeinstellung deaktivieren).

2. Zugriff auf Proxyeinstellungen und Proxydaten selber per GPO festsetzen. Alles kommt direkt von der Domäne und man muss nicht an jeden Rechner einzeln ran. Hat dafür den Nachteil, daß die Einstellungen dann nicht für lokale Anmeldungen gelten und die trotzdem weiter ändern können.

Hoffe das war was du wolltest,
Grüsse,
ufo2012
ufo2012 27.10.2009 um 10:52:11 Uhr
Goto Top
Hallo BtodaR,

kurze Nachfrage: Du hast also eine GPO für die User eine OU mit den Proxy-Einstellungen erstellt. Quasi unter
Benutzerkonfiguration/Windows-Einstellungen/Internet Explorer-Wartung/Verbindung/Automatische Browserkonfiguration?

Und die User können diese Einstellung dann noch ändern?

mfg

heiko
manuel-r
manuel-r 27.10.2009, aktualisiert am 18.10.2012 um 18:39:47 Uhr
Goto Top
Hatten wir in ähnlicher Form kürzlich hier schon mal. Die Suche hätte dir das bestimmt auch geliefert.
Btodar
Btodar 27.10.2009 um 14:42:49 Uhr
Goto Top
erstmal danke an alle Antwortern:

@RedRabbit:

Lokale Sicherheitsrichtlinien halte ich für nicht praktikabel (150 User). Die User sollen aber weiterhin Zugriff auf die Proxyeinstellungen behalten. Deswegen möchten wir diese nicht per GPO deaktivieren.

@ufo2012:

Ich habe eine GPO erstellt und diese direkt an die Domäne verknüpft. Also keine eigene OU. Liegt hier vielleicht das Problem?

@manuel-r:

Hab ich wohl überlesen... Entschuldigung. Trotzdem sehe ich in dem Thread keine Hilfe für mein Problem... Weil selbst bei mehrmaligem Ab- und Anmelden die Proxyeinstellungen nicht wieder überschrieben wurden und auch mehrere Neustarts nicht geholfen haben.

So weit ich mich erinnere, war das unter 2003 nicht so problematisch...

MfG BtodaR
ufo2012
ufo2012 27.10.2009 um 14:54:33 Uhr
Goto Top
nein, das sollte kein Problem sein, dass Du die GPO gleich an die Domäne verknüpfst. Hast Du vielleicht eine weitere GPO, die diese wieder ausstechen könnte? Hast du beim User schon einmal mit "gpresult" überprüft, ob die Richtlinie greift?


mfg
Btodar
Btodar 27.10.2009 um 15:16:15 Uhr
Goto Top
Wir haben nur noch die Default-GPOs, wo wir aber nichts eingestellt haben... Also keine anderen GPOs.
gpresult gibt mir für diesen Benutzer auf dem bestimmten Client aus, dass das Proxy-GPO angewenden wird.
Das gibt mir ja auch neue Rätsel auf.

Das GPO wurde ja erfolgreich angewandt, nur werden, nachdem der Benutzer die Einstellungen manuell geändert hat, die Einstellungen nicht wieder mit denen der Domäne überschrieben...

Soll ist's zumindest angedacht...

MfG BtodaR
manuel-r
manuel-r 27.10.2009, aktualisiert am 18.10.2012 um 18:39:47 Uhr
Goto Top
In dieser Antwort habe ich ausführlich erklärt, warum das GPO nicht nochmal angewandt wird und was du dagegen tun kannst. Lesen bildet...
Btodar
Btodar 27.10.2009 um 16:40:00 Uhr
Goto Top
Vielen Dank für die nette Antwort.

Also komme ich um die Batchdatei nicht herum, die bei jeden Anmelden ausgeführt wird und "gpupdate /force" drin stehen hat?!?

Die Benutzer brauchen dann locker 5 - 10 Sekunden länger zum Anmelden und werden damit nicht zufrieden sein.

Gibt es wirklich keine Alternative, wenn ich den Zugriff auf die Proxyeinstellungen weiterhin erlauben möchte?

MfG BtodaR
manuel-r
manuel-r 27.10.2009 um 17:31:42 Uhr
Goto Top
Wer's von den Benutzern, aus welchem Grund auch immer, in die eine Richtung umstellen kann wird in der Lage sein es auch wieder in die richtige Richtung umzustellen würde ich mal behaupten.
Es geht wahrscheinlich darum, dass die User zu Hause surfen wollen und da der interne Proxy nicht vorhanden ist. Erstens halte ich das grundsätzlich mal für ein latentes Sicherheitsrisiko und zweitens könntest du das automatisieren. Aber auch dazu brauchst du entweder ein passendes (Kix-)Script oder ein entsprechendes Tool.
Ausgehend von der grundsätzlichen Möglichkeit, dass die Clients im Firmen-LAN in einem anderen Subnet arbeiten könntest du die zugeteilte (DHCP?) IP abfragen und je nach Ergebnis den Proxy entsprechend setzen.
DerWoWusste
DerWoWusste 27.10.2009 um 22:54:34 Uhr
Goto Top
@RedRabbit
... Hat dafür den Nachteil, daß die Einstellungen dann nicht für lokale Anmeldungen gelten und die trotzdem weiter ändern können.
Das ist ein Missverständnis. Du schreibst von einer computerobjektbasierten Policy - die sind nicht userabhängig und gelten natürlich auch bei lokaler Anmeldung.