Fragensteller
Gruppenrichtlinie mit Zeitsteuerung

Frage
-
Wir benutzen in einer Windows 2003 Serverumgebung zur Bereitstellung von Druckern die Druckverwaltung in Verbindung mit Gruppenrichtlinien. Das Bereitstellen funktioniert ohne Probleme.
Allerdings lassen sich über die Druckverwaltung keine Standarddrucker vorgeben.
Deshalb nutzen wir ein Skript ,um den Standarddrucker zu setzen. Beides spielt in einer Standardserverumgebung ohne Fehler zusammen.
In einer Konstellation ergibt sich aber der Fehler, dass am XP-Client die über die Druckverwaltung installierten Drucker (computerspezifisch) während der Benutzeranmeldung noch nicht fertig gebunden oder installiert sind. Das Skript für den Druckerstandard (userspezifisch) findet deshalb noch keinen installierten Drucker vor und kann deshalb auch keinen als Standard setzen. Das Skript erzeugt eine Fehlermeldung.
Ist es möglich die Gruppenrichtlinie für das Setzen des Druckerstandards zeitverzögert zu starten oder erst definiert nach dem erfolgreichen Abarbeiten der Richtlinie für die Druckverwaltung?
Alle Antworten
-
Am 27.12.2010 schrieb Jenny Frank:
Wir benutzen in einer Windows 2003 Serverumgebung zur Bereitstellung von Druckern die Druckverwaltung in Verbindung mit Gruppenrichtlinien. Das Bereitstellen funktioniert ohne Probleme.
Allerdings lassen sich über die Druckverwaltung keine Standarddrucker vorgeben.Also funktioniert es doch nicht ohne Probleme. Meinst du die
Bereitgestellten Drucker?
http://www.gruppenrichtlinien.de/HowTo/Bereitgestellte_Drucker.htmDeshalb nutzen wir ein Skript ,um den Standarddrucker zu setzen. Beides spielt in einer Standardserverumgebung ohne Fehler zusammen.
Weshalb nicht gleich alles in einem? Script für die Drucker und
gleichzeitig den Standarddrucker setzen.
http://www.gruppenrichtlinien.de/HowTo/Anmelde_Scripts.htmIst es möglich die Gruppenrichtlinie für das Setzen des Druckerstandards zeitverzögert zu starten oder erst definiert nach dem erfolgreichen Abarbeiten der Richtlinie für die Druckverwaltung?
Möglicherweise habt ihr die beiden Einstellungen aus der GPO-FAQ No.
36 nicht gesetzt. http://www.gruppenrichtlinien.de/Grundlagen/faq.htmServus
Winfried
Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
GPO's: http://www.gruppenrichtlinien.de
Community Forums NNTP Bridge: http://communitybridge.codeplex.com/ -
Hi,
Am 27.12.2010 15:10, schrieb Jenny Frank:
zur Bereitstellung von Druckern die Druckverwaltung in Verbindung mit
Gruppenrichtlinien.Lass das bitte sein.
Allerdings lassen sich über die Druckverwaltung keine Standarddrucker
vorgeben.... einer der Gründe, warum du es sein lassen solltest.
http://www.gruppenrichtlinien.de/HowTo/Bereitgestellte_Drucker.htmDeshalb nutzen wir ein Skript ,um den Standarddrucker zu setzen.
dann kennst du ja eine der bessere Alternativen, als die Druckverwaltng.
Die Lösung heisst: Script oder Group Policy Preferences, die ohne
Probleme in einem 2003 AD mit XP verwendet werden können.Tschö
Mark
Mark Heitbrink - MVP Windows Server - Group Policy
Homepage: www.gruppenrichtlinien.de - deutsch
GPO Tool: www.reg2xml.com - Registry Export File Converter
NNTP Bridge: http://communitybridge.codeplex.com/releases -
Hallo Winfried,
Hallo Mark,
ich schätze und nutze Eure Beiträge zur täglichen Arbeit.
Beim Thema Druckerskripting scheiden sich aber die Geister. Wir haben uns zu diesem Thema in der Vergangenheit mehrmals dazu gegenseitig ausgetauscht.
Ich habe in der Vergangenheit das Skripting zur Druckersteuerung wie von Euch vorgeschlagen mehrfach angewendet.
Allerdings kam es in den zurückliegenden 1-2Jahren zunehmend zu nachweisbaren und reproduzierbaren Problemen mit Druckertreibern bei namhaften Druckerherstellern.
Wir konnten über das Skripting die sichere Installation von Treibern und das Durchsteuern von Druckereigenschaften nicht mehr sicherstellen.
Seit einem Gespräch auf der Cebit 2010 mit einem namhaften Microsoft-Supportmitarbeiter haben wir bei den Problemfällen auf "Druckverwaltung" umgestellt und damit die Probleme beseitigt. Es gibt noch Handlungsbedarf z.B. beim Löschen von Druckern, aber auch das kann geleistet werden. Das Setzen des Standarddruckers ist auch über Skripts machbar. Insgesamt ist die Lösung zuverlässig und überschaubarer als das Skripting.
Nur in einem Anwendungsfall bei dem eine pädagogische Software die Benutzerprofilverwaltung übernommen hat, kommt es zu den besagten Problemen. In diesem Fall wird zunächst die Druckerverwaltungsrichtlinie aktiv. Die Drucker werden vorbereitet, installiert. Allerdings sind im Benutzerprofil (Roaming-Profil) Druckereinstellungen vorhanden, die an diesem Platz nicht angewendet werden können und den Prozeß verzögern. In diesem Moment wird aber bereits die GPO für das Setzen des Standarddruckers aktiv. Da aber noch kein Drucker fertig installiert ist, kann in diesem Moment auch noch kein Standarddrucker gesetzt werden. Es kommt zu dem besagten Fehler.
Somit bleiben mir zwei Möglichkeiten: Entweder ich kann das Setzen des Standarddruckers hinauszögern oder, und das wäre mir lieber,
ich finde die Ursache dafür, was das Druckermanagement hinauszögert.
Was sagt Ihr dazu?
-
Hi,
Am 02.01.2011 20:08, schrieb Jenny Frank:
Allerdings kam es in den zurückliegenden 1-2Jahren zunehmend zu
nachweisbaren und reproduzierbaren Problemen mit Druckertreibern bei
namhaften Druckerherstellern.Da geht es dir leider wie allen anderen und ich habe auch das Gefühl,
daß es schlimmer wird.Wir konnten über das Skripting die sichere Installation von Treibern
und das Durchsteuern von Druckereigenschaften nicht mehr
sicherstellen.Egal ob:
rundll, con2prt, pushprintersconnections, GPP Printer
JEDE! dieser Methoden verwendet dieselbe Technik, sie installiert,
besser gesagt sie kopiert, die Treiber aus der Freigabe des
Druckservers.Mit einem Unterschied: Bei der rundll Methode im Script könntest du
auf eine alternative .inf Datei verweisen.Seit einem Gespräch auf der Cebit 2010 mit einem namhaften
Microsoft-Supportmitarbeiter haben wir bei den Problemfällen auf
"Druckverwaltung" umgestellt und damit die Probleme beseitigt.Hm, ich wüsste nicht, was daran besser sein sollte, denn die
Methode an sich ist absolut identisch, es darf keinen Unterschied
machen, ob ich per DLL eine AD/LDAP Abfrage mache und daraufhin
den Treiber vom Druckserver kopiere, oder ob ich den Druckserver
direkt per Script oder GPP anspreche. Der Druckserver kann mir
nur den Treiber liefern, den er selber bereitstellt.Wer hat dir denn das gesagt? Schick mir mal bite eine PM, das
würde mich echt interessieren.Da aber noch kein Drucker fertig installiert ist, kann in diesem
Moment auch noch kein Standarddrucker gesetzt werden.Das Problem kriegst du auf keinen Fall mit deinem Weg gelöst.
Du verwendest/kombinierst 2 verschiedenen Client Side Extensions.
In dem Moment ist nicht allein die Reihenfolge der Richtlinien
entscheidend, sondern die Reihenfolge in der die CSEs durch die
Reihe der Richtlinien laufen.Skripte (10) laufen vor den "Bereitgestellte Druckern" (20) und auch
vor den "GPP Drucker" (28)Das kannst du nur lösen, in dem du es mit einer einzigen CSE realisierst
oder eine verwendest, die den Standarddrucker "nachträglich" einstellen
kann.... und schon wieder habe ich einen Punkt mehr auf der Liste, warum
man die Bereitgestellten Drucker nicht verwenden kann :-)Siehe:
http://www.gruppenrichtlinien.de/Grundlagen/Client_Side_Extensions.htmTschö
Mark
Mark Heitbrink - MVP Windows Server - Group Policy
Homepage: www.gruppenrichtlinien.de - deutsch
GPO Tool: www.reg2xml.com - Registry Export File Converter
NNTP Bridge: http://communitybridge.codeplex.com/releases -
Hallo Mark,
ich bin ja Leihe, gebe mich aber nicht geschlagen!
Mit "Bereitgestellte Drucker" werden die Treiber sicher installiert. Das ist und war aber nicht das drängenste Problem.
Über den Druckmanager lege ich Standarddruckereinstellungen fest, die sind wichtig und werden nur über das von mir beschriebene Verfahren richtig und reproduzierbar übertragen.
Kann man das über Skripts genauso schnell und einfach erreichen?
Beispiel: Installiere HP LJ P3015DN, Standardpapierfach: Fach 1, Druck: mono
Ich finde da keine bessere Lösung. Auch HP wollte mich diesbezüglich nicht unterstützen! Es sei nicht ihre Aufgabe!
mfg
jf
PS: Den Kollegen von Microsoft kenne ich aus X-Foren. Und ich berufe mich sehr gerne auf ihn, aber ich habe seinen Namen aktuell nicht parat. Der Stress! Wenn es klick macht, gebe ich den Namen durch! Versprochen!
-
Hallo Mark,
noch eine Nachfrage:Ich habe mir die Sache mit den CSEs angesehen.
Was bedeutet dies aber für die Reihenfolge der Gruppenrichtlinienabarbeitung:
Ich bin immer davon ausgegangen, dass innerhalb einer OU die Abarbeitung einer GPO im Client, wie oft beschrieben, quasi hierarchisch abläuft.
Mit den CSEs scheint es aber eine Präferierung zu geben. Ist das richtig?
mfg
jf
-
Hallo Mark,
folgender Fall liegt vor:
Es gibt folgende Struktur:
OU_Business
Computers
GPO_Bereitgestellte Drucker
GPO_Standarddrucker Skript
Users
etc.
Ich bin davon ausgegangen, dass die GPO_Bereitgestellte Drucker unter allen Umständen zuerst abgearbeitet wird und dann erst die GPO_Standarddrucker Skript. Stimmt das oder bestimmt die CSE die Reihenfolge?
Danke für Deine Hilfe!!
mfg
jf
-
Hi,
Am 04.01.2011 23:08, schrieb Jenny Frank:
Ich bin immer davon ausgegangen, dass innerhalb einer OU die
Abarbeitung einer GPO im Client, wie oft beschrieben, quasi
hierarchisch abläuft. Mit den CSEs scheint es aber eine Präferierung
zu geben. Ist das richtig?Ich glaube du meinst es richtig ...
Grundsätzlich gibt es eine Reihenfolge der Richtlinien die alleine
auf der Hirarchie der OU Struktur, bzw.
L(ocal)-S(ite)-D(omain)-OU basiert, oder auch an einer OU von oben
nach unten sortiert ist, aber:Stell dir vor du hast Richtlinien, in denen mehrere Komponenten (CSE)
beteiligt sind:Reihenfolge der GPOs: GPO1, GPO2, GPO3
GPO1: Registry, Security, Scripte
GPO2: Registry, Scripte
GPO3: SecurityAus Process-Sicht und anhand der DLL Aufrufe, wäre eine ORdnung
der Verarbeitung nach GPO Reihenfolge schlecht, denn es müssten
in dem Beispiel 3 DLLs immer wieder aufgerufen werden und wieder
beendet werden.Flasche ORdnung dieser DLL/Process Aufrufe:
Registry, Security, Scripte, Registry, Scripte, SecurityDer Rechner wäre ständig damit beschäftigt DLLs zu laden und
wieder beiseite zu legen.Also gibt es eine Ordnung anhand der CSEs, diese ist hardcodiert nach
"Sinnhaftigkeit" festgelegt worden und diese arbeitet sich jetzt durch
die Reihenflge der GPOs:Richtige Sortierung nach DLL/Prozessoptimierung
CSE1 Registry verarbeitet: GPO1, GPO2
CSE2 Script : GPO1, GPO2
CSE3 Security : GPO1, GPO3Im Gegensatz zum ersten/flschane Beispiel haben sich die 6 DLL Aufrufe
auf 3 reduziert und es kommt zum gleichen Ergebnis, aber wesentlich
performanter.Was dazu führt, das man niemals dieselben Dinge mit 2 verschiedenen
CSE machen sollte, denn dann ist nicht die Reihenfolge der GPOs
relevant, sondern die Reihenfolge der CSEs.Dieser Fehlerfall ist aber sehr selten, wenn man mal von
ADM Templates (Registry) und der GPP Registry absieht, oder alles
was mit Scripten möglich ist, oder oder oder :-)
Sagen wir mal MS geht davon aus, das die Leute nicht die ADM Settings
für den IE verwenden UND! die GPP Internet Explorer, sondern sich auf
eine Baustelle einigen und damit ist das Problem gelöst.
Eine Baustelle = Eine CSETschö
Mark
Mark Heitbrink - MVP Windows Server - Group Policy
Homepage: www.gruppenrichtlinien.de - deutsch
GPO Tool: www.reg2xml.com - Registry Export File Converter
NNTP Bridge: http://communitybridge.codeplex.com/releases -
Danke Mark für Deine Erklärung:
Demnach wäre es in meinem Fall so, dass
1. Skriptrichtlinien und dann
2. Deployed printer Connections
verarbeitet würden.
Was ich dann wiederum nicht verstehe ist, warum
meine vorgegebene Reihenfolge bei allen Installationen bis eben auf einer funktioniert.
Gibt es noch eine Idee, wie ich über ein Skript, die Druckereinstellungen sauber durchsteuern kann?