Unable to Print to Network Installed Printer

I have had some issues regarding customers not being able to print to network installed printers using the Viewer's "Print".

The print dialog which comes up shows any of these printers using the UNC path (\\<machine>\), with or without a share name (if given) and as well its name and\or the device name (i.e. \\<machine>\(<share name>) <Device Name>) but the print job itself never goes through and effectively never attempts to send it to the spool\queue regardless of attempt.

However, if the printer is instead installed as a Local printer, it shows up as only the Printer Name or Share Name at that point and prints perfectly fine. 

The PDFs have been generated using your Generator namespace and exist only in memory at any given point, so they are always being passed through as byte[].  The only difference seems to be the way the dialog sees and references the print which makes a difference.

Is there something I'm missing with why the network shared printer is making the Viewer fail to even attempt to print in this instance?

It'd be hard to post any code which makes sense to the problem as it is using your default Toolbar in order to perform this function.

Neither the PDF nor the OS nor the Printer make/model seem to make a difference to the problem.

Hello,

We have tested the print functionality of the Viewer as per the scenario you have described and we are able to send the print job successfully to the network printer using the UNC path \\<machine>\<share/device name>. In case you are using an older build please make sure to update your application to use the latest build (v1.0.1.24892) which can be obtained from the customer area. If the latest build does not resolve the issue then please check and make sure that the user account running the application has permissions to print to the network printer. 

Thanks,
ceTe Software Support Team.

Well, that is ultimately what is confusing me.  To be sure, yes I am using the latest v1.0.1.24892 reference.

I apologize for not including this information previously, however, I can also verify that the user *can* print to the same network printer.  In the instances I am referencing, the user can also use the "save" button to save the report to a file, open it in Adobe Reader, and print it just fine on the *same* printer.  So they absolutely have permissions to print (and it shows up in the printing spool, etc just fine). 

In the particular cases I was trying to diagnose I tried with one user who was a local Administrator on the machines, and another user which was a Domain Administrator (and was the user/login which installed the printer both on the server and the machine).  I ran the program with and without elevated privileges as well just to make sure of that premise as well.

If there is any other information I can try to provide, I'm more than willing to try, it's a bit befuddling to me currently.  Especially because, as you've also stated, I can also go through several iterations of network printers, OS's and sharing from one machine to another, etc. where it does work fine. So I'm wondering if there's any other restrictions, requirements, etc. the printing process itself requires which perhaps .NET or the resolving of the printer itself is somehow missing?

What I also don't seem to be able to replicate (though I haven't exhaustively tried yet) is the Name this particular case shows, which is:

\\SERVER\(ShareName) Device Name

Most all iterations I've gone through ends up showing only
\\SERVER\ShareName
or
\\SERVER\Device Name
but not both, if that makes sense. (or simply DeviceName when installed via local driver installation, of course)

I also noticed that in the instance of the ShareName, the printer is being shared as, say "sharename".  It is showing up in the list of printers as "Sharename", regardless of removing and re-adding the printer as well, if that helps or has anything at all to do with it...

Hello,

Other than the permissions, there are no additional requirements or restrictions for the printing using DynamicPDF Viewer for .NET. From what I understand based on your last two posts, if the network printer is installed via local driver installation the Viewer can print without any issues. However it is unable to print when UNC path to the printer is used. Here are a few questions so we can better understand the issue:

1. Does it print correctly to printer with UNC path \\SERVER\ShareName or \\SERVER\DeviceName and fails to print to printers with UNC path \\SERVER\(ShareName) Device Name ? In other words, does it matter what the printer’s UNC path looks like? Or does it fail for all printers when UNC path is used?

2. Does printing via UNC path work on certain machines and not on other machines? If so have you found any differences between those machines?

Please email us at support@cete.com with the above information referring to this forum post. Include any other relevant information along with the following screenshots.

1. Screenshot of the machine’s “Devices and Printers” list.
2. Screenshot of the Viewer’s print dialog showing the list of printers and identify the printers in the list to which the Viewer is unable to print to.

Thanks,
ceTe Software Support Team.

I was trying to wait until I could get back to the client machines, etc. in question before posting back.  However, I haven't been able to get back to the client(s) in question in order to provide the requested screenshots as of yet.

Nonetheless, I can at least comment on the rest.

The initial restatement you provided seems aptly put as far as I have been able to tell.

1. On the infrastructure where it is failing, it did not seem to like any UNC path reference-able printer (I believe they have at least 2-3 different printers in this instance).  I got the feeling the locally installed printer iteration may have only *worked* because its "resolved reference" within the print dialog was simply a Name even though it was still a "networked printer".

2. As far as I could diagnose along with communicating with the users there, it was seemingly machine and user independent (i.e. didn't work regardless of System User type nor 32/64 bit machines).

--
As stated above, I have not been able to get back to grab the requested screenshots, but hopefully I can soon as I am sure they are still awaiting an answer one way or another in order to deploy to the rest of their machines as well as for future reference, etc.
--

In terms of any sort of permissions-relevant issue, could it be an elevation of privilege (or .NET request/demand of security principle via remnants of CAS, SRP, AppLocker, APTCA, etc.)?  On my end, I do not think I have provided little more than nearly a direct reference to just this component for what its worth.

If there is anything else I have provided which I might be able to explain better or even perhaps informationally expound upon, please let me know in the meantime.

Hello,

We are unable to recreate this issue at our end. We are able to print to the shared network printers without any issues. I have added a shared network printer by going to these options, Devices and Printers --> Add Printer --> Add Network, Wireless or Bluetooth printer --> Find A Printer By Name --> I have given the UNC path of the printer here (\\ServerName\PrinterName). This has installed the printer drivers. I could see the UNC path of the printer when I have opened the print dialog from the Viewer.

Please let us know how did you install the shared printers? Did it install the drivers? Also is there any shared sessions mirrored printer (ie. printers showing automatically when connecting to a remote desktop)?

Could you please give us the screenshots we have requested in earlier post? Also please give us the printer names and OS environment details. Please send these details to our support team at support@cete.com.

Thanks,
ceTe Software Support Team.

I still have a VB6 application being used and have just recently seen this same issue occurring with you old VB6 control.
This application uses Crystal Reports to generate the PDF which we print in the background with your old OCX control.
The report viewer can send to the printers that fail with your OCX control.
I guess it is not just .Net

Good to know that I'm not crazy and/or posting about what would have seemed to be a "me" problem.

However, I don't think I could ever nail it down to a completely systemic issue across multiple machines\networks\printers per the above postings.

In my case it seemed to still point at possibly a document compatibility issue with how this product generates and\or manipulates PDFs in general.

Hello,

Version 1 and 2 of DynamicPDF Viewer for COM/ActiveX product support printing to network printers and we are unable to recreate the issue.

We’d recommend trying version 2 on your end and see it works for you. You can download the version 2 installer by logging into our CustomerArea: CustomerArea using your version 2 DynamicPDF Viewer COM/ActiveX product serial number. Before installing v2, please make sure to completely uninstall the v1.

Please note that the DynamicPDF Viewer does not edit or modify the PDFs. It just reads the PDFs and open it for viewing in the Viewer control.

Thanks,
ceTe Software Support Team