Bereitgestellte Drucker - Drucker Veröffentlichung

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!

Wer ein Active Directory mindestens mit der Schemaerweiterung des Windows Server 2003 R2 im Einsatz hat und auf seinen Server die neue Druckerverwaltung installiert hat, findet sowohl in der Benutzer- als auch in der Computerkonfiguration den Punkt: Bereitgestellte Drucker

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 XP/2003 Benutzer, bzw. Computer? Nichts. Garnichts. Nicht mal ein Fehler. Warum?  Erst Vista bringt hierfür eine eigene CSE (Client Side Extension) mit.

Allen ältere Clients ignorieren die Anweisung, da sie nichts damit anfangen können. Es gibt eine EXE (pushprinterconnections.exe) , die per Scriptaufruf die Bereitgestellten Drucker aus den Richtlinien ausliest und dann die Übernahme verarbeitet.

Für meinen "alten Clients" komme ich 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.

1. Grundvoraussetzung ist natürlich mindestens ein Windows Server 2003 R2 und seine neue Druckerverwaltung und das SchemaUpdate. Die Konsole muss zuerst auf einem Server installiert werden, ab 2008 als Rolle. In diese Verwaltung können hinterher weitere Server integriert werden, andere 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. 
2. Bereitstellung eines Druckers. Das kann über 2 Wege geschehen:
   a) über die Gruppenrichtlinie selber
   b) über die Druckerverwaltung.
3. Für den Client muss jetzt noch sein Anmeldescript angepasst werden. 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.
4. 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. 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.
9. Kennt ihr eigentlich den Unterschied zwischen "gut gemeint" und "gut gemacht"?
   Wir schon, aber *piiiiiiiiiiiiiiieeeeeeeeeeeeeeep* wohl nicht.

Der Beweis, das es nichts taugt ist in Vista gut zu sehen:

In Windows 7 ist es tatsächlich korrigiert worden, ich verrate nicht, welcher mir gut bekannte MVP laut genug drüber gelästert hat damit das stattgefunden hat ;-).

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 den vorhandenen ADM/ADMx manipuliert werden ... bei REG_BINARY scheidet das aus. Ein ADM / ADMx kann keine REG_BINARY!

Man wird die Werte sicherlich auch als REG_DWORD integrieren können und ich gehe davon aus, daß es funktioniert, 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.