I am using "WScript.Shell" and the "Exec" method instead of the "Run"
method because the exe requires the shell to be navigated to its
directory before execution, which I can set with "CurrentDirectory"
property.
Using the following code the exe reports an error accessing the shared
printer:
Set objWShell = CreateObject("WScript.Shell")
objWShell.CurrentDirectory = "C:\LabelExe\"
objWShell.Exec("label.exe labelfile.txt -P\\IT3\LabelPrinter")
After reading up on the subject I have found that ASP code runs under
the IWAM_<machinename> account which does not have logon interactive
privilages, meaning it cannot access the shared printer. The answer to
the solution would be to execute the "WScript.Shell" as a different
user (impersonation).
I have tried using the MS Impersonation DLL found here:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q248187
making sure that the IWAM account had user rights to "act as part of
the operating system" in "Local Sec Policy>Local Policies>User Rights
Assignment" and the following code:
set objLogon = Server.CreateObject("LoginAdmin.ImpersonateUser")
objLogon.Logon "adminuser", "adminpassword", "domain"
Set objWShell = CreateObject("WScript.Shell")
objWShell.CurrentDirectory = "C:\LabelExe\"
objWShell.Exec("label.exe labelfile.txt -P\\IT3\LabelPrinter")
...
Although when I queried the "WScript.Network" object for the current
user after the call to objLogon.Logon the user had changed to my
domain user the exe would still fail to connect to the shared printer.
In this groups post (http://groups.google.co.uk/groups?hl=en&lr=&ie=UTF-8&selm=uYGFLq5yCHA.1928%40TK2MSFTNGP10)
it appears that "WScript.Shell" will always revert back to the IWAM
user no matter if you are impersonating or not.
I have tried various third party components and the whole "run as"
route also to get round the problem. The only solution that I have
found is to lower the "Application Protection" setting in IIS to "Low"
which then runs the ASP code in the IIS Process using the "system"
account which does have the right privilages to access the printer
share.
I need my IIS server to remain on Anonymous Access "ISUR" and keep my
Application Protection set to "Medium" and get this exe to access the
shared printer by some means.
Please could someone shed some light on the problem. I have read that
I might be able to wrap the exe as a DLL and install the DLL as a COM+
component running under an account with sufficient rights to the
printer? Is this the best way of solving my problem?
Thanks, Mark
Since you want to put my name in lights ... after all
this is addressed to me
How many ASP coders does it take to print a label across the
network?
3 to get on the phones with MS Paid Support, 2 to configure
the firewall, 2 to read the referenced the support KB articles,
and one to copy and paste the resolution code.
I hear General Meyers is using ASP for system administration
at the Remote War room in Tampa. They contract out for support
to Dell's Outsourcing in New Delhi, India.
LoL,
Keep forgin those headers and goofin off...