USB network shared printer command line printing

[Pop]

Hi, i am trying to automate the printing of a file on a USB printer that is shared on the network from an end user computer. To be clear i have successfully accomplished this on an AD installed networked printer, wondering why it's not working on a USB network shared printer.

Here are the details:
I have a pdf file that needs to be printed automatically every morning, on 2 different printers. Those are our evacuation lists. I have scripted a powershell script that calls the print on the printers from the command line, that is:
.\PDFXEdit.exe /print:printer="\\HOST\PRINTER_SHARE_NAME" $todayFile (executing from the software directory, hence the .\)
No issues here. This is a networked printer (wired) that is installed directly on the Active Directory server and shared by it.

Now i would like to do the same with a USB printer that is network shared from an end user computer, that still has a UNC name like this: \\HOSTNAME\PRINTER_SHARE_NAME
but it won't work. I tried both IP address and Hostname, and same with printer name/share name. I am sure that PDF xchange can accomplish this, as when i open the file from the software i can easily print on that printer, no hassle. But from the command line nothing happens. Command runs (no errors from anything) but nothing happens.

I have tried putting the printer on the LPT1 port as per Gemini`s suggestion, to no avail. I tried using the USB001 port as that is what the server hosting the file and software are showing me as the port, still to no avail. I have verified the firewalls on both ends. I also tried to print a regular text file using a bunch of other native command line tools, and still nothing.
I can provide the script i wrote if that helps but that's just 5 lines: setting up my file name, changing directory to executable path and running the command line for PDFXedit.exe. I'm also trying to accomplish this without scripting for the moment to make sure it works.

ANY suggestions are welcome. only thing i can think of that i have not tried yet since we're in a corporate environment is to deactivate the firewall on the end user's end, which i doubt will change anything as the command seems to execute, according to powershell output (tried the same in command prompt if that can reassure you).

Thank you.

[Sean - PDF-XChange]

Hi Pop,

The issue here is the difference between printing to a real network / print-server printer, and a USB printer that’s shared from a user’s computer. A printer installed on a server is available system-wide and accepts jobs from scripts, services, and scheduled tasks. A USB printer shared from a workstation only exists in that user’s logged-in session. When you print interactively it works, but when PowerShell or Task Scheduler runs under SYSTEM, admin, or a service account, that printer does not exist in that context and Windows fails silently.

The first thing to check is whether the printer is visible to the account running the script. If the printer does not appear when listing printers from that same account, the script cannot print to it. The best solution for you is to move the printer to a server and share it from there.

If it must remain USB-shared:

• Run the scheduled task as the same logged-in user who owns the printer.
• Or install the printer while logged in as the service account that runs the script.
• Make sure credentials to the host PC are stored and valid.
• Disable “Point and Print Restrictions” if enforced by group policy.

To isolate whether it’s PDF-XChange or not, try printing a simple text file using Windows’ built-in printing. If that fails, the issue is Windows, not your command. I hope that helps.

Kind regards,

[Pop]

...
The first thing to check is whether the printer is visible to the account running the script. If the printer does not appear when listing printers from that same account, the script cannot print to it. The best solution for you is to move the printer to a server and share it from there.

If it must remain USB-shared:

• Run the scheduled task as the same logged-in user who owns the printer.
• Or install the printer while logged in as the service account that runs the script.
• Make sure credentials to the host PC are stored and valid.
• Disable “Point and Print Restrictions” if enforced by group policy.

To isolate whether it’s PDF-XChange or not, try printing a simple text file using Windows’ built-in printing. If that fails, the issue is Windows, not your command. I hope that helps.

Kind regards,

Hi Sean,
I will answer your questions for future references to the post, and i will post my solution at the end.

Yes the printer is accessible from the account running the script. Like mentioned in my OP, i can print the same document using the software without any issue, and it is the same account running the command line, which is an admin account if that makes a difference.
-It's a no-network printer, so it has to stay USB shared. (i'm not in control of purchases and budget so not my decision.)
-The printer is already installed and working just fine with anything else, from that same machine
-The creds are stored and valid. Tried using a PScredential object to use with the script, tried using credentials manually in plain text and also tried without any credentials (which to my knowledge would use the credentials of the account running the command line, and if needed would ask for other credentials in case it doesn't have access to the device.
-"Point and print restriction" is not enabled/enforced in GPOs
And i have printed a normal .txt file using PRINT /D:<devicename> X:\Path\To\File from a non-elevated command line.

Our solution: we used GhostScript and wrote a small python app since it did not seem possible to do with the command line options of PDFXedit.exe.

Thank you for your time.

[Daniel - PDF-XChange]

Hello, Pop

I am glad to hear that you were able to resolve the issue on your own, and sorry for the confusion from Sean's post. If you are still looking for a solution without your python script, I believe that using a path was the root cause of the issue here.

So long as the printer is visible to your current device (no matter how it is shared), it should be visible to your current device with a simple printer "name". The best way to find this "name" is to use the Powershell "Get-Printer" command, then use the Name displayed there for your command. The system should handle the rest without the need to provide a full path.

If it does not appear in this list, that would mean the print-device is not accessible by the system.

Kind regards,

[Pop]

Well, after some testing today i figured it out: the problem stems from powershell. Most likely the interpreter: this does not work in powershell, yet works just fine in command prompt. And that is both as non-admin and admin. The ONLY difference is the ".\".

Powershell:
.\PDFXEdit.exe /print:printer="\\192.168.200.112\Brother MFC-L5700DW series" "C:\Path\to\file.pdf"
Command prompt:
PDFXEdit.exe /print:printer="\\192.168.200.112\Brother MFC-L5700DW series" "C:\Path\to\file.pdf"

and yet, this works just fine in powershell:
.\PDFXEdit.exe /print:printer="\\192.168.200.1\e-imp-photocopieur" "C:\Path\to\file.pdf"

The only differences between the 2 printers is that 1 is a USB printer, shared from an end-user computer over the network, and the other is shared by an Active Directory server. AND if i use the share name instead of printer name for the usb one, nothing is working, but i believe that is a UNC "issue" in windows. (actually cannot change a USB printer's name, only it's share name, as far as i know, and all our AD shared printers have the same name and share name, to lower confusion).

Thank you for your time again guys, much appreciated.

[Sean - PDF-XChange]

Hi Pop,

Great - glad you were able to get to the bottom of this. If you have any further questions, please just get in touch.

Kind regards,