Using Scheduled Tasks with PDFCreator

We are trying to schedule print jobs using Scheduled Tasks on on several W2K3 SP2 machines using PDFCreator version 0.9.8 and 0.9.9. The print job will fail if there is an administrator logged onto the console of the computer when the print task runs. Has anyone successfully done this?

The scheduled print tasks are configured to run under an administrative account (doesn't seem to run for non-administrative accounts but that's a different problem). Everything runs properly if there are no other users logged onto the computer.

If there is a different administrative user (or any other user?) logged onto the computer the print will not execute. The logged on user sees the 'PDFCreator Print Monitor' application try to start but it does not start correctly. Print Monitor is only partly visible with corrupted graphics. The user can minimize Print Monitor to the system tray.

At this point, if the administrative user logs off and the Scheduled Task user logs on, we can't start the PDFCreator GUI. We have to manually kill the PDFCreator.exe process first. We can then start PDFCreator GUI again. The print job is then visible, it runs and will complete.

The easiest way to replicate this is to create a scheduled task which will run a PDFCreator print job and set it to run under the USERA account (must be administrative). Select to run the scheduled task now, it will run correctly. Log off account USERA and log on as USERB administrator. Select to manually run the scheduled task now again. It will fail.

Hmmm, no replies?  Either this is a really simple issue or nobody prints via scheduled tasks.

Anyone? Can you print successfully schedule print jobs to run when nobody is logged onto the computer?

Hi,

 

I print with the windows scheduler and encountered pb too. But not exactly the same. See my post dated 01/19/2010.

Unfortunetaly, I can't say more at the moment .

 

MgVx

(messed up formatting; see next)


I am running a PowerShell script as a scheduled task.  It kills all instances of PDFCreator, then creates a new instance of PDFCreator using COM, then it sets some options, then leaves that instance running.  After that, a program gets run which prints to the default printer (PDFCreator).  This seems to work whether a user is logged on or not.

# Kill any active PDFCreator processes; cleans up any previously created mess,
# prevents issues with COM (sometimes it doesn't return...)
Get-Process |? {$_.Name -eq "PDFCreator"} |% {$_.Kill()}

# Changes to options are only for the current instance; they are not saved!
$oPDFCreator = New-Object -ComObject "PDFCreator.clsPDFCreator"

If(! ($oPDFCreator.cStart("/NoProcessingAtStartup"))) {Throw "Could not connect to PDFCreator via COM to set options"}

# Turn on Autosave functionality
$oPDFCreator.cOption("UseAutosave") = 1

# Specifies PDF format
$oPDFCreator.cOption("AutosaveFormat") = 0

# Enable specifying the directory to save to
$oPDFCreator.cOption("UseAutosaveDirectory") = 1

# Save the files to this folder
$oPDFCreator.cOption("AutosaveDirectory") = "C:\\CBORDWin\\ETM\\ETMImportReports"

# Format of the filename <> indicates tags that get substituted
$oPDFCreator.cOption("AutosaveFilename") = "ETMImportLogReport_"

# Don't run a program after saving (i.e. Acrobat Reader)
$oPDFCreator.cOption("AutosaveStartStandardProgram") = 0

# Set the standard date format
$oPDFCreator.cOption("StandardDateformat") = "YYYY-MM-DDTHHNNSS"

# Tells the printer to start printing; otherwise, everything just queues
$oPDFCreator.cPrinterStop = $False

# Remmed out - leave it running so FMS uses this instance
# $oPDFCreator.cClose() | Out-Null

# Release the COM object; otherwise the PDFCreator.exe process stays running
# While ([System.Runtime.InteropServices.Marshal]::ReleaseComObject($oPDFCreator) -gt 0) {}
# $oPDFCreator = $Null

I was having a similar issue. When more than 1 user logged into my print server my PDF documents would print blank. It has something to do with multiple user bother running the PDF Creator at the same time. (didnt have time to debug further than that) My work around was to disable PDF Creator as an auto start application in MSCONFIG.


1)  I connect to my remote server via RDP with a print account. This is the same account being used to run  the Scheduled Task that does batch printing. 

2) Manually start PDF Creator and minimize it into the task bar (or just leave it windowed)

3) Disconnect (not log off)

4) Profit.


*** I haven’t looked around too much, but you may also be able to set up for PDF Creator to only auto-start for a specific user name. I know Microsoft’s standards RDP client has an option to start an application on login. ***