Hi, We've been using the SDK for 10 years (since v2) without problems. A customer has now updated to Windows Server 2016 and printing is not working. It looks to be the same issue as this,
but before we make any changes can you confirm which user the command line runs as when run from the SDK - does it inherit the IIS user the application is running under or does it pick up SYSTEM user?
For the SDK if we need to 'run as' what are the steps? We are also on V2 would we need to upgrade to be able to run as?
Thanks for your message, yes, I understand this problem, this is because the restrictions in system user account, because system user may not "see" all printers, the system user has some limitation on network connection also.
In order to overcome the restrictions in system user account, you should better run PDFPrint Command Line inside an interactive user account instead of system user account.
When you run pdfprint.exe inside a normal user account, pdfprint.exe will able to see all installed printers and able print to network printers without any problem.
If you are using PDFPrint SDK, you need set the calling application run inside an interactive user account or a normal user account to instead of system user account, you can also write a simple command line application based on PDFPrint SDK, and then call this command line application from your main application with "RunAs" or CreateProcessAsUser() function, you will able to get PDFPrint SDK work from an interactive user account.
>>but before we make any changes can you confirm which user the command line runs as when run from the SDK - does it inherit the IIS user the application is running under or does it pick up SYSTEM user?
For your question, you may run pdfprint.exe or your SDK calling application from administrator user account, you can use RunAs or CreateProcessAsUser() or VeryDOC's CmdAsUser.exe or "VeryPDFComRunCmd COM Component" to run an EXE application from administrator user account, this can be done easily.