Wie schon User ilnic im Open Forum beschrieben hatte, habe ich das Problem, dass auf der Installation auf dem Terminalserver (W2003) Spoolverzeichnisse "C:\\Documents and Settings\\user\\Local Settings\\Temp\\PDFCreator\\Spool" und "C:\\Documents and Settings\\user\\Local Settings\\Temp\\2\\PDFCreator\\Spool" angelegt werden.
Wird standardmäßig gedruckt (über die Druckerauswahl) eigentlich kein Problem. Es wird dabei das Verzeichnis "C:\\Documents and Settings\\user\\Local Settings\\Temp\\PDFCreator\\Spool" (ohne ID) verwendet. Sobald nun der PDFCreator über die COM-Schnittstelle angesprochen wird erstellt er nun ein weiteres Spoolverzeichnis mit der ID ("...Temp\\2\\PDFCreator\\Spool"). Abgelegt werden die Spoolfiles aber im "alten" Verzeichnis (ohne ID) und der PDFCreator scheint nun ins "Leere" zu laufen.
Erst nach einer Neuanmeldung auf dem Terminalserver werden die Spoolfiles wieder im Print-Monitor angezeigt und können weiterverarbeitet werden.
Verwendete Version 1.3.2, Tests auch mit 1.4.1 (möchte aber nicht wie der User ilnic auf 1.2 downgraden, was aber anscheinend geholfen hatte, denn dann müsste ich auch alle anderen User downgraden).
Installation wie für Terminalsserver beschrieben durchgeführt.
Mittlerweile ist das Problem erkannt. (MS legt scheinbar den Temp-Pfad einer Konsolenanmeldung je Windowsversion willkürlich fest.) WinXP, Win2003: C:\DOKUME~1\\LOKALE~1\Temp Vista, Win7: C:\Users\\AppData\Local\Temp Win2008, Win 2008R2: C:\Users\\AppData\Local\Temp\
was ich dabei aber nicht verstehe ist da folgende:
Auch wenn die verschiedenen Windows Versionen Ihrer Temp Pfade in einer Consolen Sitzung anders anlegen, im Falle von Windows 2008 R2 ist laut der Ausgabe des Befehls set immer die SeesionID im Temp Path enthalten, egal ob Console oder RDP Sitzung. Wieso verhalten sich die Ausdrucke über PDFCreator oder z.B. über testpage2PDF.vbs unetrschiedlich ? Bei RDP Sitzung wird in beiden Fällen nach ..\\Temp\\\\PDFCreator\\Spool gespoolt, und bei Consolensitzung nur unter testpae2PDf.vbs. Der Ausdruck über PDFCreator landet direkt unter ..\\Temp\\PDFCreator\\Spool . Da die Programme bzw. Scripte aber die gleichen geblieben sind, bin ich ein wenig verwundert, dass der PDFCreator das TempVerzeichnis so unterschiedlich ermittelt. Der Programmcode dürfte doch der gleiche sein.
Aus dem ganzen folgere ich, dass das testpage2ODF.vbs script vermutlich die %Temp% Variable abfragt, der PDFCreator selber aber nicht. Wenn dieser eine MS Routine abfragt, scheint diese wohl unetrschiedlcieh Ergebnisse zu liefern. Kann der PDFCraetor nicht einfach auch nur die %Temp% Variable abfragen, dann dürfte doch alles gegessen sein. Da die alten Versionen ja noch mit der PrinterTempPath arbeiten konnten udn alles wie erwartet spoolte, setzt diese Variable doch einfach intern fest auf den Wert %Temp%.
ganz so einfach ist die Sache nicht. Nicht das Programm PDFCreator hat Probleme den richtigen Temp-Pfad zu ermitteln, sondern die Monitor-DLL. Diese läuft im Kontext der Anmeldung des SpoolerSubSystems, im Allgemeinen LocalSystem. Um den PDFcreator richtig zu starten, muss die Monitor-DLL zuerst die richtige Benutzer-Sitzung ermitteln und danach die Umgebung(svariablen) für den Prozess. Und hier macht MS etwas was ich noch nicht ganz verstehe. Die entsprechende API-Funktion verwendet dazu immer die Werte aus HKEY_CURRENT_USER\Environment. Und dort steht nie eine SessionId. Anscheinend wird nach einem Anmeldeprozess der Temp-Pfad je nach Betriebssystem und ob Konsole oder RDP nochmals angepasst. (Nebenbei zusätzlich noch in Abhängigkeit einer Gruppenrichtlinie, die aber wohl keiner verwendet.) Und hier fehlen mir die nötigen Informationen wie MS vorgeht.
Für Tipps bin ich dankbar. Eine zusätzliche Einstellung PrinterTempPath möchte ich aber aus folgendem Grund nicht verwenden. Kommt es hier zu einem Fehler und die Einstellung steht auf C:\ oder auf Eigene Dateien könnten Daten des Benutzers gelöscht werden.
hatte mri schon gedacht, das MS hier das Problem darstellt. Aber wo ist der Unterschied in der Ermittelung des Temp Pfades, wenn ich direkt aus dem PDFCreator drucke, oder wenn ich über testpage2.vbs, bzw. den anderen Scripten etwas ausgebe ? Werden hier andere DLLs genutzt ?
Die Idee mit der PrinterTempPath Variable hatte ich folgendermaßen gedacht :
Sie sollte aus den bekannten Gründen nicht über die Registry zu ändern sein, da sie aber die einzige war die in alten Versionen funktioniert hat, sollte es doch möglich sein, sie intern zu verwenden und intern mit %Temp% zu besetzen. Wenn sich nun jemand selber seinen Temppfad über die Umgebungsvariablen auf c:\\ legt, so wird dieser als Basis-Temppath genommen, wenn man sich dann aber über die CMD die %Temp% ausgibt, steht dort der Basis-Temppath mit angehängter SesseionID ! Zu sehen übrigens auch unter HKCU\\Volatible Environment.
Das unter HKCU\\Environment nur der Basispfad steht, hat seinen Grund darin, dass ein Benutzer die Möglichkeit hat mehrere Sitzungen gleichzeitig auf einem TS aufmachen zu können. Findet man des öfteren z.B. in Krankenhäusern, wo alle Schwestern einer Station die gleiche Anmeldung über mehrer PCs gleichzeitig nutzen. Diese Anmeldung landen alle unter dem gleichen HKCU auf dem TS. Damit die Sitzungen auseinander gehalten werden können, was z.B. das Druckern TempPath etc. betrifft wird dann jeder Sitzung die SessionID angehängt. Unter HKCU\\Volatible Enviroment sieht man dann die einzelnen Sitzungen. Da es nun ein Problem sein dürfte, die richtige Sitzung herauszubekommen, wenn ein Anwender mehrmals angemeldet ist, habt Ihr eigentlich nur die Chance direkt die %temp% abzufragen.
Ich dachte es wäre einfacher für Euch die PrinterTempPath Variable intern weiter zu nutzen, weil Sie schon überall enthalten ist und si enur am Anfang anderesmit einem Wert zu besetzen, als alles umbauen zu müssen.
Gruß Cranger
PS: Ein Wunsch noch für eine neuere Version: Es wäre schön, wenn man dem Benutzer die Möglichkeit nehmen könnte nicht selber auf Updates zu prüfen zu können. Auch wen ich per GPO das Intervall auf "Nie" setzen kann, so könnte ein TS User immer noch selber auf Updates prüfen. Kommt auf einem TS nicht ganz so gut, besonders wenn ein Anwender evtl. höhere Rechte bekommen hat.
Bei mir besteht das Problem auch mit der 1.5.0 immer noch: - der Druckerspooler legt den Job unter …\temp\0\PDFCreator\Spool\ ab - und der PDF-Spooler sucht vergebens in …\temp\PDFCreator\Spool
Der Zugriff erfolgt auf ein anderen PC oder VirtualPC mit RemoteDesktop.
Arbeite ich direkt am Rechner, funktioniert alles bestens. Sobald ich die Sitzung mit Remotedesktop übernehme bzw. mich damit anmelde, dann tritt dieses Verhalten auf.
@racoon80: Eigentlich sollte das Problem mit der Version 1.4.2 behoben sein. Bist Du sicher, dass Du nach der Installation einen Neustart durchgeführt hast? Welche Version hat die Datei pdfcmon.dll im Pfad C:\\Windows\\System32?
ich habe mich jetzt etwas in diesem wierklich informativen Forum umgesehen und eigentlich das gefunden was ich suche.
Ich möchte ein Wasserzeichen mit einem Briefkopf ersetzen. Ich habe jetzt in einem Beitrag gelesen, dass man ein Script in einen Speziellen Platz. ( C:\\Program Files\\PDFCreator\\Scripts\\RunProgramAfterSaving) Bei diesem Verzeichnis ist auch noch eine PDF Datei atermark.pdf. Wie kann ich meinen Briefkopf als Wasserzeichen einfühgen?
leider existiert dieses Problem immer noch mit der neuesten Version 1.4.3. Die Ursache konnte ich daran festmachen, dass bei Windows Server/Terminal Server Installationen jeder angemeldete Benutzer aufgrund seiner Session ID ein eigenes temporäres Verzeichnis zugewiesen bekommt.
In diesem Fall werden die über den Drucker gespoolten Dateien im jeweiligen Unterordner
\\\\PDFCreator\\Spool\\
abgelegt. Der PDFCreator selbst scheint das temporäre Verzeichnis aber über eine anderen Windows API Methode auszulesen und schaut nur in den Unterordner
\\PDFCreator\\Spool
und findet dort natürlich keine Dokumente zur Verarbeitung.
Daher müsste mal im Source Code geprüft werden, warum die Ermittlung des Verzeichnisses beim Druckspooler über eine andere Methode erfolgt als im PDFCreator selbst. Dies müsste "einfach" nur vereinheitlicht werden. Dann funktioniert es überall, egal ob auf einem Terminal Server oder nicht.
scheint in v1.4x außer Betrieb und wird schmerzlichst vermisst.
Den kompletten User-Temp-Path in der Systemkonfiguration wird man wohl kaum umstellen, damit die Spool-Datein des PDFcreators 'ausgelagert' werden können...