IIS Printing (Help Required!)
-
NT4 SP6/IIS4/Baffled Programmer. We have a need on our internet for the users to print a file from an ASP page, the file is destined for the default printer of the IIS server (Simple enough?). Currently we are creating a scripting object: Set WshShell = Server.CreateObject("WScript.Shell") That then calls a batch file: WshShell.Run "c:/temp/lhead.bat" The batch file executes OK when called standalone, but when executed on the back of IIS failed to write anything to LPT1. (It currently simply contains DIR > LPT1) Is there some kind of security restriction that I should be looking at? Is there an easier way of achieving this?
-
NT4 SP6/IIS4/Baffled Programmer. We have a need on our internet for the users to print a file from an ASP page, the file is destined for the default printer of the IIS server (Simple enough?). Currently we are creating a scripting object: Set WshShell = Server.CreateObject("WScript.Shell") That then calls a batch file: WshShell.Run "c:/temp/lhead.bat" The batch file executes OK when called standalone, but when executed on the back of IIS failed to write anything to LPT1. (It currently simply contains DIR > LPT1) Is there some kind of security restriction that I should be looking at? Is there an easier way of achieving this?
Further to this I know think I know why, but I'm still looking for a way around it. I've swopped the WScript.Shell component for ASPExec, if I now exec notepad through ASP then attempt to print, it fails to write to lpt1, (Notepad is running as SYSTEM). If I manually start notepad (as the logged on user) and print it works. So the problem appears to be with SYSTEM tasks accessing the printers, do anyone know about this?
-
Further to this I know think I know why, but I'm still looking for a way around it. I've swopped the WScript.Shell component for ASPExec, if I now exec notepad through ASP then attempt to print, it fails to write to lpt1, (Notepad is running as SYSTEM). If I manually start notepad (as the logged on user) and print it works. So the problem appears to be with SYSTEM tasks accessing the printers, do anyone know about this?
Maybe this kind of access must be run in its own process. The IUSR_ account is only allowed to run InProc. To access process that require OutOfProc you must use an account with such previleges. One way is to create a com-component, add it to the MTS and assign it to run under a specified user account, and then add that account to the security settings in DCom Config Manager (which you start from Start --> Run "DCOMCNFG"). Be sure to test this in a labb environment: I had some problems when I tested this for reaching Excel functionallity from IIS. Knowledgebase article Q198432 at MS' site has more info about this. Good Luck! Consultant, system/web developer. IMS Consulting AB, Sweden
-
Maybe this kind of access must be run in its own process. The IUSR_ account is only allowed to run InProc. To access process that require OutOfProc you must use an account with such previleges. One way is to create a com-component, add it to the MTS and assign it to run under a specified user account, and then add that account to the security settings in DCom Config Manager (which you start from Start --> Run "DCOMCNFG"). Be sure to test this in a labb environment: I had some problems when I tested this for reaching Excel functionallity from IIS. Knowledgebase article Q198432 at MS' site has more info about this. Good Luck! Consultant, system/web developer. IMS Consulting AB, Sweden
Thanks for that, I have track the problem down to Q184291 COM Objects fail to print when called from ASP. The bottom line is the system account that is running IIS does not have any printer ports by default. The article describes copying then from the default user. This fixes the problem is the printer is local but not if its a network printer. I found a few nice ASP printing objects on the web that get around that one but in my instance the printer is on a remote Netware print server. I gave up at this point, reconfigured my Unix server to print to the Netware box and hey presto! Regards, Kevin.