Bents Blog

 

Ein IT Blog mit Themen aus dem Windows Server Umfeld.

Best Practices: PDFCreator – Update des kostenfreien PDF-Druckers als Dienst im Netzwerk

Vor circa einem Jahr berichtete ich in meinem Artikel Kostenfreier PDF-Drucker im Netzwerk als Dienst unter Windows Server 2008 R2 über die relativ einfache Möglichkeit, mit Hilfe der Software PDFCreator einen zentralen PDF-Druckserver als Dienst bereitzustellen. Obwohl das Programm für die Ausführung als Dienst nicht vorgesehen ist, lässt sich diese Lösung dennoch umsetzen. Meine alte Beschreibung bezieht sich auf die Version 1.2.3 des PDFCreator, das hier vorgestellte Update betrifft die (zum Zeitpunkt der Artikelerstellung) aktuelle Version 1.4.3.

Änderungen

Die wichtigste Veränderung des PDFCreator stellt wohl der Verzicht auf den bis Version 1.2.3 verwendeten Druckauftrag-Umleitungs-Dienstes REDMON (Redirection Port Monitor) dar. Bisher konnte man bei Einsatz der alten Version auf Umgebungsvariablen des REDMON (wie etwa REDMON_USER, REDMON_PRINTER oder REDMON_FILENAME) zugreifen – diese entfielen ab Version 1.3.0 mit dem Einsatzes des eigenen Port-Monitors PDFCreator Port (pdfcmon.dll). Auf Grund dieser Tatsache ändern sich alle bisherigen Einstellungen innerhalb des PDFCreator für die automatisierte Ausführung als Dienst. Leider gab es von der Version 1.3.x bis 1.4.2 Probleme bei der Erzeugung der PDF-Dokumente, wenn das Programm als Dienst gestartet wurde – aus diesem Grund empfehle ich keine vorherige Version einzusetzen.

Voraussetzungen und Funktionsweise

Die Voraussetzungen für den Einsatz des PDFCreator haben sich auch in der neuen Version nicht geändert:

  • Windows-Domäne mit zentraler Ablage der Benutzer-Basis-Ordner (Eigene Dateien)
  • Gruppenrichtlinie für die automatische Ordnererstellung (PDF-Dokumente)
  • Druckserver (ab Windows Server 2003 bis zu Windows Server 2008 R2)
  • Freeware: PDFCreator für die Erstellung der PDF Dokumente via Ghostscript
  • VBS-Skript SetACL.vbs für das Setzen der Dateiberechtigungen

Die Funktionsweise des angepassten PDFCreator ist dabei die Folgende:

  1. Benutzer Mustermann druckt beliebiges Dokumentes auf den zentralen PDF-Drucker
  2. PDFCreator (Dienst auf Server1) konvertiert Druckauftrag in ein PDF-Dokument <Dokument-Mustermann.pdf>
  3. PDFCreator speichert  PDF-Dokument unter \\Server2\User\Mustermann\Eigene Dateien\PDF-Dokumente\<Dokument-Mustermann.pdf>
  4. Aufruf des VBS-Skriptes SetACL.vbs um Mustermann Vollzugriff und das Besitzrecht für <Dokument-Mustermann.pdf> zu erteilen

Das folgende Bild soll die Funktionsweise verdeutlichen – im Schritt 1 wird der Druckauftrag erstellt, im Schritt 2 wird das Dokument in das PDF-Format konvertiert, im Schritt 3 im Benutzer-Ordner gespeichert und kann im Schritt 4 vom Benutzer geöffnet werden: Da der PDFCreator später die Dokumente im Speicherbereich des jeweiligen Benutzers erstellt – in meinem Beispiel unter

\\Server2\User\<Benutzer-Alias>\Eigene Dateien\PDF-Dokumente

so kann dieser Unterordner über eine Gruppenrichtlinie automatisch für jeden Benutzer bei dessen Anmeldung erzeugt werden. Diese Einstellungsmöglichkeit findet man in dem gewünschten Gruppenrichtlinienobjekt unter Benutzerkonfiguration, Einstellungen, Windows-Einstellungen, Ordner. Selbstverständlich können der Druck- und Datei-Server ein und die selbe Maschine sein – in diesem Fall würde der Speicherbereich lokal angesprochen werden.

Installation

Sollte eine ältere Version des PDFCreator vorhanden sein, empfehle ich die Deinstallation des selbigen – zuvor sollten die bestehenden Profile der eingerichteten Drucker exportiert werden. Bei Aufruf der Installationsroutine des PDFCreator in der Version 1.4.3 muss zunächst der Expertenmodus aktiviert werden: Nach der Bestätigung der Lizenzbedingungen ist als Installationsart der Servermodus auszuwählen: Schließlich ist noch der Name das Druckers einzugeben (Voreinstellung PDFCreator, dieser kann später jederzeit geändert bzw. neu erstellt werden. Soll der PDFCreator auf einem 64 Bit Betriebssystem (bspw. Windows Server 2008 R2) installiert werden, der Drucker aber auch von 32 Bit Clients verwendet werden, so muss der folgende Haken aktiviert werden: Für die Funktion des PDFCreator als PDF-Netzwerkdrucker sind die beiden Programme Images2PDF und PDFArchitect nicht erforderlich, beide können in der Komponentenauswahl deaktiviert werden. Nach erfolgreicher Installation des Programmes müssen nun einige Systemanpassungen vorgenommen und im Anschluss die Programmeinstellungen an die Umgebung angepasst werden. Die Verknüpfung des PDFCreator sollte unbedingt aus dem Autostart-Ordner entfernt werden, da dieser Probleme bei zweimaliger Ausführung verursacht. An dieser Stelle kann das VBS-Skript SetACL.vbs für das Setzen der Dateiberechtigungen des PDF-Dokumentes in den Zielordner

C:\Program Files (x86)\PDFCreator\Scripts\RunProgramAfterSaving\

kopiert werden.

Einrichtung

Diensterstellung

Zunächst erfolgt die Einrichtung des PDFCreator als Server-Dienst. Dafür benötigt man zwei Programme aus dem Windows Ressource Kitsrvany.exe und instsrv.exe (beide Tools sind auch voll unter Windows Server 2008 R2 funktionsfähig). Die Datei srvany.exe kann bspw. nach C:\Windows kopiert werden, die Syntax für die manuelle Registrierung des Dienstes auf Kommandozeilenebene würde in diesem Fall wie folgt lauten:

instsrv PDFCreator C:\Windows\srvany.exe

Im Anschluss kann mit Hilfe des Kommandozeilen-Befehls

sc description PDFCreator “Netzwerk-PDF-Drucker”

eine Beschreibung des Dienstes definiert werden. Danach muss die Registrierung um folgende Einträge ergänzt werden, um die Ausführung des PDFCreator für den eben erstellten Dienst zu hinterlegen (die Pfade sind entsprechend anzupassen):

[HKLM\SYSTEM\CurrentControlSet\Services\PDFCreator\Parameters]
REG_SZ:Application:"C:\Program Files (x86)\PDFCreator\PDFCreator.exe"
REG_SZ:AppDirectory:"C:\Program Files (x86)\PDFCreator"

Soll der PDFCreator die erzeugten Dokumente später auf einem anderen Server speichern, muss der Dienst unter einem Benutzer-Account gestartet werden, der über Schreibrechte auf dem Zielserver verfügt:

Programmeinstellungen

Bevor der Dienst nun gestartet werden kann, muss der er zunächst über die PDFCreator Einstellungen konfiguriert werden. Dies gilt im Übrigen auch für Änderungen an der Konfiguration – hier muss der Dienst zunächst beendet werden, bevor selbiger nach den Änderungen wieder gestartet werden kann. Die relevanten Einstellungen für den Dienst Betrieb betreffen die Programm-Punkte Automatisches Speichern und Aktionen. Die Erzeugung des Dateinamens geschieht durch den Einsatz sogenannter Token. Welche Token benutzt werden können, erschließt sich aus der Hilfe. Wer mein VBS-Skript SetACL.vbs nutzen möchte, dem empfehle ich die folgenden Token für den Dateinamen zu verwenden:

<Title>-<Author>-<DateTime:dd_mm_yyyy>-<Counter:00000>

Dabei  besteht der Token <Title> aus dem um Sonderzeichen bereinigte (durch „_“ ersetzt) Dokumenten-Name, gefolgt von <Author>, dem Benutzer der den Druckauftrag erzeugt hat. Achtung: Niemals den Token <Username> nutzen, dieser entspricht dem Benutzer unter dem der Dienst PDFCreator ausgeführt wird und führt somit zu Fehlern. Im Anschluss füge ich noch die Token <DateTime:dd_mm_yyyy> und <Counter:00000> an, beides sind formatierte Variablen die das aktuelle Datum und den fortlaufenden Druck-Zähler enthalten. Warum diese Formatierung? In der alten Version des PDFCreator wurde bereits die Variable <DateTime> genutzt – mit dem Vorteil, dass sie während der PDF-Dokumenten-Erzeugung nur einmal zu Beginn gesetzt wurde. Leider hat sich das Verhalten geändert. Da die Variable im Standard auch die Sekunden enthält, die im Programm-Punkt Aktionen zur Namensbildung wiederverwendet werden muss (da die frühere Variable „OutputFilename“ nicht mehr existiert!), kommt es bei größeren PDF-Dokumenten zu Fehlern vom Aufruf des VBS-Skriptes SetACL.vbs. Damit nun keine Dateien mit dem selben Dokumenten-Namen des selben Benutzers am gleichen Tag überschrieben werden, wurde der 5-stellige Zähler-Token <Counter:00000> angefügt (dieser kann bei Bedarf beliebig vergrößert werden). Eine äußerst nützliche Funktion bietet die Möglichkeit, Token auch im Pfad für die automatische Speicherung zu benutzen – in meinem Beispiel ist das der Token <Author>, der so das Benutzer-Verzeichnis anspricht:

\\Server\User\<Author>\Eigene Dateien\PDF-Dokumente

Selbstverständlich können hier auch lokale Verzeichnisse angegeben werden – bswp. in dem Fall, in dem der PDFCreator lokal auf dem Server installiert wird, auf dem sich auch die Benutzerverzeichnisse befinden. Im Programm-Punkt Aktionen lässt sich nun die Datei-Behandlung nach ihrer Erstellung konfigurieren. Dabei wird im Reiter Aktion nach dem Speichern als Skript das zuvor kopierte SetACL.vbs ausgewählt. Als Programmparameter erwartet das Skript die drei Paramater Ausgabe-Datei, Author und Drucker-Name – durch Leerzeichen getrennt. Diese können durch die folgenden Werte erzeugt werden:

„\\\Server\User\<Author>\Eigene Dateien\PDF-Dokumente\<Title>-<Author>-<DateTime:dd_mm_yyyy>-<Counter:00000>.pdf“ <Author> „<PrinterName>“

Die erste Kombination in Anführungszeichen bildet unseren Dateinamen (Pfad kann Leerzeichen enthalten). Achtung: Befindet sich der Pfad im Netzwerk, bitte drei Backslashes verwenden – das erste wird leider von PDFCreator „verschluckt“. Danach wird über <Author> der Benutzer des Druckauftrags angegeben, gefolgt vom Drucker-Namen <Printername>, der wiederum Leerzeichen enthalten darf (auf Grund der Verwendung der Anführungszeichen).

Update vom 28. Januar 2013

Inzwischen wurde der PDFCreator auf die Version 1.6.2 aktualisiert. Nach meinen Tests sind die oben beschriebenen Probleme behoben, es genügt nun die Angabe folgender drei Parameter für den Aufruf des Skriptes:

„<OutputFilename>“ <Author> „<PrinterName>“

Alle Einstellungen werden nun durch die Schaltfläche Speichern übernommen. Das Skript sorgt später bei der Ausführung für die Zuweisung der Rechte Vollzugriff und Besitzer für den angegebenen Benutzer auf der erstellten Datei.

Update vom 17. April 2013

Ich habe eben einen Test mit der neuen PDFCreator Version 1.7.0 durchgeführt und im gleichen Atemzug auch mein Skript SetACL.vbs angepasst. Die neue Version ist nun die 1.4 und behebt ein Anzeigeproblem der Quelle im Ereignisprotokoll.

Update vom 24. April 2014

Inzwischen habe ich die Skript-Version 1.5 zum Download bereit gestellt, die ich bereits erfolgreich mit der aktuellen Version 1.7.2 des PDFCreators auf einem Windows Server 2012 R2 im Einsatz habe. Ich habe im Skript eine verbesserte Fehlerkorrektur implementiert und die Behandlung von Sonderzeichen eingeführt, die in der alten Version bei einigen Dokumenten zur Problemen geführt hat. Aktuell verwende ich im PDFCreator (in Kombination mit meinem Skript) die folgenden Einstellungen. Für das Automatische Speichern nutze ich als Dateiname folgende Kombination:

<DocumentFilename>-<Author>-<DateTime:dd_mm_yyyy>-<Counter:00000>

Im Anschluss nutze ich  unter Aktionen nach dem Speichern als Programmparameter folgende Werte:

„\\\<Server>\PDF-Druck\<Author>\<DocumentFilename>-<Author>-<DateTime:dd_mm_yyyy>-<Counter:00000>.pdf“ <Author> „<PrinterName>“

pdfcreator-action-aftersave Mit dieser Konfiguration funktioniert in meinen Umgebungen alles zufriedenstellend.

Ausführung und Test

Nach dem Speichern der Einstellungen kann der erstellte Dienst PDFCreator erstmals gestartet werden. Der angelegte Drucker muss nun für die Verwendung im Netzwerk nur noch freigegeben und auf den gewünschten Clients verbunden werden. Automatisiert kann das wiederum über eine Gruppenrichtlinie erfolgen. Nach dem Druck einer Testseite als Benutzer Testuser erhält dieser – in meinem Beispiel – die folgende Datei im Unterordner PDF-Dokumente in seinen Eigenen Dateien:

Testseite-Testuser-13_08_2012-00032.pdf

Ich denke, an diesem Beispiel wird deutlich, wie die verschiedenen Token bei der Erstellung des Dokumenten-Namen wirken. Auf dem Server, auf dem PDFCreator als Dienst arbeitet, erzeugt das VBS-Skript SetACL.vbs außerdem einen Eintrag im Anwendungsereignisprotokoll: PDF-Drucker-Skript [Skript-Name] auf [Druckservername] Drucker: [Printername] Dokument: [Dokumenten-Name] Speicherort: [Pfad zum Dokument] Benutzer: [Domäne]\[Author] Dateigröße: xx,x KBytes Bei einem Fehler wird hier entsprechend eine Fehlermeldung protokolliert.

Besonderheiten

Der PDFCreator eignet sich auf Grund der Möglichkeit zur Erstellung unterschiedlicher Profile für den Einsatz mehrerer freigegebener PDF-Drucker, die automatisch unterschiedliche Dokumenteigenschaften erzeugen können (bspw. Passwortschutz, digitale Signaturen oder Kompatibilitätseinstellungen). Dazu können im Menü der PDFCreator – Einstellungen mehrere Profile definiert, ex- und importiert werden. Die Profile können im Anschluss im PDFCreator unter Drucker hinzugefügt und das gewünschte Profil zugeordnet werden: In der Systemsteuerung erscheint ein neuer Drucker nicht als eigenes Objekt, sondern wird in den Druckeinstellungen und Druckereigenschaften zur Auswahl angeboten: Erst dadurch wird der PDFCreator meiner Meinung nach zu einer extrem umfangreichen, flexiblen und variantenreichen Lösung.

Fazit

Der obige Beitrag soll als Hilfestellung und Anregung für die Umsetzung eines zentralen PDF-Druckers mit automatischer Speicherung für die einzelnen Benutzer einer Domäne dienen. Es gibt professionelle (und kostenpflichtige) Varianten, die meist einfacher und mit etwas weniger Aufwand umzusetzen sind. Dafür bietet die beschriebene Lösung einen flexiblen Einsatz, da verschiedene Profile für unterschiedliche Einstellungen mehrerer Drucker erstellt werden können. Die Einrichtung ist in kurzer Zeit abgeschlossen und als Kosten fallen nur die Arbeitszeit an. Wie bei allen meinen Beiträgen gilt: Bei Tipps, Vorschlägen sowie Fragen oder Kritiken hinterlasst bitte einen Kommentar.

Einen Blog am Leben zu erhalten kostet Zeit und Geld. Da ich auf meiner Seite weder Werbung einbinde, noch andersweitige Zuwendungen erhalte, freue ich mich über jede kleine Spende. Einfach und unkompliziert geht das über PayPalMe. Du unterstützt damit diesen Blog. Vielen Dank.

Kommentare für “Best Practices: PDFCreator – Update des kostenfreien PDF-Druckers als Dienst im Netzwerk”

  • Bent Schrader

    Auf Grund der am 25. Mai 2018 in Kraft tretenden europäischen Datenschutz-Grundverordnung wurden alle Kommentare abgeschaltet und gelöscht. Damit wird die Erhebung personenbezogener Daten vermieden. Das DSGVO wurde von Professor Thomas Hoeren zu "einem der schlechtesten Gesetze des 21. Jahrhunderts" gekürt, mit der Bemerkung, dass überbordene Werk sei "hirnlos". Ich bedaure sehr, das damit die Möglichkeit zum Austausch von Informationen von Gleichgesinnten verhindert wird.