Bereitgestellte Drucker - Drucker Veröffentlichung mit Windows Server 2003 R2


Microsoft Quellen:
"Step-by-Step Guide for Print Management"
"Deploy printers by using Group Policy"
"Extending Your Active Directory Schema in Windows Server 2003 R2"


Ein privater Kommentar vorweg:
Nur damit es von vornherein zu keinen Missverständnissen kommt: Ich verabscheue diese Form der Integration in die GPO zutiefst.
Gründe dafür folgen am Ende des Artikels, aber wer daran denkt diese Krücke im produktiven System einzusetzen, dem sind sicher
auch schon an anderen Stellen massive Fehler unterlaufen ...
Die Funktion der "Bereitgestellte Drucker" und die damit verbundene "pushrpintersconnection.exe" ist gelinde gesagt, der letzte Dreck!
Nur weil ein Auto ein Ersatzrad besitzt ist das noch lange kein Grund es benutzen zu wollen oder gar zu müssen!

Wenn man sein Active Directory mit der Schemaerweiterung des Windows Server 2003 R2 im Einsatz hat und den Gruppenrichtlinien-Editor öffnet, wird man von einem neuen Punkt überrascht, der sich in der Computer~ und der Benutzerkonfiguration wieder findet.

Es sei an dieser Stelle noch mal kurz erwähnt das das für die Schemaerweiterung benötigte adprep.exe !ZWINGEND! von der 2ten CD der R2 CD verwendet werden muss.

-> Bereitgestellte Drucker


(zu sehen, wenn man schon die neue Druckerverwaltung installiert hat)

So simpel die Konfiguration erscheint, so wenig Möglichkeiten sie bietet, so seltsam ist auch das Verhalten ...
Die erste und einfachste aller Ideen ist: Ich stelle einen Drucker bereit und nach Anwendung der Gruppenrichtlinie steht er dem Benutzer (oder auf dem Computer) bereit. Der Drucker wird übergeben, der Treiber wird aus der Freigabe kopiert, also wie "immer".

Aber was passiert bei einem 2K/XP/2003 Benutzer, bzw. Computer? Nichts. Garnichts. Nicht mal ein Fehler.

Gemeinerweise kommt uns hier der Terminplan von Microsoft in die Quere. MS hoffte die Veröffentlichung von Vista zeitnah zur Release der R2 zu realisieren. Was aber nicht geklappt hat. Vista lässt weiter auf sich warten (ich glaube 1Q/07 ist jetzt der Termin) aber der R2 ist schon für Vista vorbereitet. Soll heissen: Bereitgestellte Drucker sind eine Funktion die Vista Clients verstehen und die auf diesen Rechnern zur Anwendung kommen.

Warum? Vista bringt hierfür eine eigene CSE (Client Side Extension) mit.
Mit anderen Worten: Windows 2000/XP/2003 übernehmen die Richtlinie, verstehen aber die Anweisung nicht, was sie damit anzufangen haben, da sie eben nicht über diese CSE verfügen.

Die erste Idee die man jetzt hat ist: Gibt es diese Funktion auch für Nicht-Vista? Wo ist das Servicepack, Update, Hotfix, Wasauchimmer-Setup.exe für diese Funktion?
Die Enttäuschung ist relativ groß, denn es wird für 2000/XP/2003 keine Integration dieser Funktion in Form einer CSE geben. 2000 ist (fast) tot, XP wird von Vista abgelöst und auf 2003 Servern installiert man Drucker per Hand. Aus dieser Sicht der Dinge ist der Testaufwand den MS betreiben müsste, um es als eine CSE zu integrieren zu groß. Es müsste jegliche Kombination der verschiedenen OS aufgebaut werden um Interaktionen mit den vorhandenen CSEs auszuschliessen. Es ist nicht nur mal eben ein Aufruf einer DLL, eine CSE stellt eine Kernkomponente für den Ablauf der Übernahme von Gruppenrichtlinien dar. Hier darf es zu keinerlei Störung kommen und aus diesem Grunde ist MS den einfacheren Weg gegangen:

Es gibt eine EXE (pushprinterconnections.exe) , die per Scriptaufruf die Bereitgestellten Drucker aus den Richtlinien ausliest und dann die Übernahme verarbeitet.
Ich komme also als Administrator an einer gescripteten Lösung für meine Druckerzuweisung nicht vorbei. Mit der pushprinterconnections.exe habe ich aber einen riesen Vorteil:
Ich muss nicht pro Drucker eine Zeile im Script erzeugen und jeden einzeln eintragen, um die Verbindung herzustellen, sondern es reicht der Aufruf der pushprinterconnections.exe und diese kontaktiert das AD, durchsucht die übernommenen Richtlinien nach den Bereitgestellten Drucker und übernimmt sie. Der Scriptaufwand wird also extrem minimiert. Es ist eine einzige Zeile für alle Drucker, die für den Benutzer oder Computer bereitgestellt werden.

Manche werden sich Fragen, wo jetzt der große Unterschied ist, einen Test mit allen Betriebsystemen und einer funktionellen EXE durchzuführen oder diesen Test mit einer DLL auszuführen.
Diese Frage lasse ich einfach mal im Raum stehen. Allen anderen kann ich nur empfehlen nicht länger darüber nachzudenken. Mein Versuch der Erklärung aus dem oberen Teil ist die Antwort. Ich habe meinen Unmut schon an der richtigen Stellte ausführlich und sehr sarkastisch geäussert, was dankend als Kritik aufgenommen wurde.

Nun ja, wat solls.

Abgesehen, von der sagen wir mal "unschönen" Integration, für alte Clients (ist schon ungewohnt im Jahr 2006 bei 2000/XP und 2003 schon von "alt" zu sprechen) stellt uns die Funktion der Bereitgestellen Drucker eine Arbeitserleichterung zur Verfügung. Wie wirds gemacht?

 
1. Grundvoraussetzung ist natürlich der Windows Server 2003 R2 und seine neue Druckerverwaltung.
  Diese muss zuerst auf einem Server installiert werden. In diese Verwaltung können hinterher weitere Server integriert werden, auch normale Memberserver, die Drucker Freigaben enthalten. Nur die Verwaltung muss über die neue Konsole geregelt sein. Sobald diese installiert ist, wird auch die neue Funktion im GPEditor verfügbar.
  Die Installation der Komponente erfolgt über: Systemsteuerung \ Software \ Windows Komponenten \ Verwaltungs- und Überwachungsprogramme \ Druckverwaltungskomponente
   
2. Bereitstellung eines Druckers. Das kann über 2 Wege geschehen:
  a) über die Gruppenrichtlinie selber
  b) über die Druckerverwaltung.
   
  Da der Weg über die Druckerverwaltung etwas ungewohnt ist, hier mal ein paar Screen Shots.
 
 
danach dem Assitenten folgen und über Durchsuchen \ bereit stellen für auswählen \ Hinzufügen :
 
 
   
  In der Druckverwaltung und natürlich auch in der GPO findet man den bereitgestellten Drucker dann wieder:
 
   
3. Für den Client muss jetzt noch sein Anmeldescript angepasst werden. Auch hier stehen wieder mehrere Mögichkeiten zur Auswahl.
  Schau euch einfach mal wieder das HowTo: AnmeldeSkripte an. Man muss ja nicht alles doppelt notieren.
  Die benötigte pushprinterconnections.exe liegt auf dem Server, auf dem die Druckverwaltung installiert wurde unter %systemroot%\PMCSnap
   
  Die pushprinterconnections.exe kennt noch "-log" als Parameter, wird dieser gesetzt wird eine *.log Datei im %temp% des Benutzers, bzw. %windir%\Temp wenn es pro Computer zugewiesen wurde erstellt. Diese beiden Pfade sind hardcodiert.
 
3a) Beispiel:
  Man kopiert die %systemroot%\PMCPSnap\pushprinterconnections.exe nach %logonserver\netlogon und verwendet sie in einem klassischen Anmeldescript und speichert die LogFiles auf einer Freigabe des Servers:
 
  %logonserver%\netlogon\pushprinterconnections.exe -log
copy %temp%\ppcUser.log \\DerServer\DieLogFileFreigabe\Printer.%username%.txt /y

 

Dem einfachen Bereistellen folgen noch eine paar offene Fragen:
(Achtung! Ironie und Sarkasmus Detektor aktivieren)

1. Wie definiere ich einen Standarddrucker, wenn mehrere Drucker über die Gruppenrichtlinien verteilt werden?
  Mit irgendeiner anderen intelligenten Lösung, da MS es versäumt hat, diese Option zu hinterlegen.
 
2. Wieso kann ich einen Drucker über die Druckverwaltung bereitstellen, aber über diese Konsole nicht wieder löschen?
  Das scheint nur so, man muss einfach den "Mit Gruppenrichtlinien bereitstellen" Wizard noch mal aufrufen,
um den Drucker aus der GPO zu löschen. Das ist so wie "Start" drücken zum "Beenden".
 
3. Warum sind die Pfade für das Logfile hardcodiert?
  weil man gedacht hat ...da MS es versäumt hat, diese Option variabel zu gestalten.
 
4. Anschliessend an 3) Wieso kann ich etwas nur lokal am dem Client speichern, was mich zentral am Server interessiert?
  Mal ehrlich:  Wen interessieren schon Protokolldateien, die sich sowieso keiner anschaut?
Der Grund warum es nicht geklappt hat steht da eh nicht drin, von daher ist das LogFile auch egal.
 
5 zu 4) Wieso muss ich auch die Kopie des Logfiles auf den Server schon wieder scripten? Das hätte man doch wohl integrieren können.
  siehe Antwort 4) schaut ja doch keiner rein.
 
6. Warum erscheint ein Drucker 2mal in der Gruppenrichtlinie, wenn ein und derselbe Drucker einmal über den GPEditor und einmal über die Druckverwaltung hinzugefügt wurde?
  weil diese beiden Programme anscheinend von unterschiedlichen Entwicklerteams bearbeitet werden, die nicht miteinander reden.
 
7. Anschliessend an 6.) Warum gibt es da keinen Prüfmechanismus, der verhindert das ein und derselbe Drucker 2mal erscheint?
  Jetzt mal nicht nörgeln, es gibt ihn doch!
Nur dummerweise überprüft der GPeditor den UNC Pfad und trägt keinen 2ten Drucker mit gleichem UNC Pfad in die GPO ein
und die Druckerverwaltung überprüft den Anzeigenamen/Veröffentlichungsnamen aus dem AD.
Was dazu führt, daß es den \\SERVER\HPLaserJet geben kann und den "HP LaserJet".
Man bekommt den Eindruck das die beiden Programme von unterschiedlichen Entwicklerteams bearbeitet werden, die nicht miteinander reden.
 
8. Wäre es denn wirklich so ein Aufwand gewesen die Funktion auch für "alte" Clients als CSE zu realisieren?
  Keine Ahnung, eleganter wäre es auf jeden Fall gewesen. Ich sehe kein Problem für eine neue Funktion ein Update einspielen zu müssen.
 
9. Warum bieten Drittanbieter (DesktopStandard, Special Operation etc.) Client Side Extensions an, der Testaufwand müsste doch der gleiche sein?
  Tja, das ist eine Frage, zu der mir wirklich nichts einfällt.
 
10. Warum werde ich das Gefühl nicht los, das es sich hier um eine "Small Business" Lösung handelt, in der es nur einen Drucker zum Verteilen gibt?
  Hehe, da komme ich selber ins Schmunzeln.
 
11. Kennt ihr eigentlich den Unterschied zwischen "gut gemeint" und "gut gemacht"?
  Wir schon, aber *piiiiiiiiiiiiiiieeeeeeeeeeeeeeep* wohl nicht.


Der Beweis:
Ich habe bis gerade nur geglaubt und gehofft, daß meine Vermutungen nur die Verzweiflung wiederspeigeln,
die mich manchmal packt, wenn ich mir diesen Mist anschaue,  aber heute bin ich über den Beweis gestolpert.

Schaut mal in die Registry und vergleicht die Werte der Client Side Extension "Bereitgestellte Drucker" (Deployed Printer Connections)
mit allen anderen hinterlegten:

Pfad zu den vorhandenen/installierten/registrierten CSEs:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions

GUID der CSE über die wir Lachen: {8A28E2C5-8D06-49A4-A08C-632DAA493E17}

Man beachte die Werte unterhalb dieser GUID, die in jeder anderen CSE auch vorkommen (können)
"NoSlowLink", "MaxNoGPOListChangesInterval", "NoGPOListChanges", "NotifyLinkTransition", "NoUserPolicy",
"NoMachinePolicy", "PerUserLocalSettings", "EnableAsynchronousProcessing", "NoBackgroundPolicy"

DAS SIND REG_BINARY! In JEDER anderen CSE sind es REG_DWORDs und können mit der vorhandenen
system.adm manipuliert werden ... bei REG_BINARY scheidet das aus. 

Man wird die Werte sicherlich auch als REG_DWORD integrieren können und ich gehe davon aus, daß es funtkioniert,
aber alleine die Tatsache, daß diese Optionen der CSE eben nicht wie alle anderen strukturiert sind ist für mich der Beweis,
daß die beiden Teams da an keiner Stelle miteinander kommuniziert haben und sie sich nicht mal die Mühe gemacht
haben nachzuschauen, wie es denn "normalerweise" mit diesen Werten in der Registry aussieht. :-(

(c) 2003 - heute, Mark Heitbrink, weitere Informationen unter WebSite-Info\Copyright