OpenPrinter Win32 API Fails from IIS After Installation of Server 2008 R2 / Windows 7 Service Pack 1 - by Sean Lower

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 749831 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 6/18/2012 4:48:33 PM
Access Restriction Public


After upgrading to Windows 7 / Server 2008 R2 SP1, calls to the Win32 API OpenPrinter() ( now fail with error code 1801 on remote queues from an ASP.NET Application running inside of IIS 7.5 when “ASP.NET Impersonation” is configured to use the Authenticated User.

ASP.NET Applications can no longer use the Anonymous Access credentials via ASP.NET Impersonation to view/administrate print jobs in remote queues.  This only occurs when Service Pack 1 has been applied to Windows 7 or 2008 R2 on the machine running IIS.

Operating System and Service Pack of the target system seem to not be a factor.

Testing with credentials stored in source code, and calling LogonUser / Impersonate calls to OpenPrinter still succeed on remote queues, even after the upgrade to Service Pack 1.

Error Code: 1801 "The Printer name is invalid"
After OpenPrinter returns FALSE, the handle passed remains NULL, and calling GetLastError() consistently returns error code 1801 (“The Printer Name is Invalid”)
Running the same code is run using the ASP.NET Development Server (VS2010) on the same machine against the same remote queue, logged in with the same user as is set in Anonymous Access then the call succeeds.

Additional Information:

.NET Framework Versions: 2.0, 3.0, 3.51

In an effort to rule out permissions issues we have tried impersonating, and application pool as Administrator.  A call to : System.Security.Principal.WindowsIdentity.GetCurrent() has confirmed the thread is running as Administrator.

PrintQueue / PrintServer Class:
As a test, we upgraded temporarily to .NET 3.0 and 3.51 and attempted to make use of the build in PrintQueue ( / PrintServer ( classes.
When calling the constructor for the PrintServer object with the path to a remote server, the following exception is thrown:
Call: PrintServer myPrintServer = new PrintServer(@"\\theServer");

Exception Thrown: "Win32 error: The printer name is invalid"

Access Flags for call to Open Printer:
We are using the following access flag : PRINTER_ALL_ACCESS
And have tried a variety of other levels, as well as passing NULL for PRINTER_DEFAULTS to attempt read only operations and it still fails.

IIS Security Settings:

Anonymous User: Set to customized user with permissions to Print, Manage Documents and Manage this Printer.
ASP.NET Impersonation: Set to “Authenticated User”

Anonymous User Tests: Logging in with the user specified in Anonymous user, the user can Install the printer, and manage jobs.  Domain/Enterprise Admins have been tested as well.  During debugging, calls to GetCurrent() Identity have confirmed the correct user

Other Access:
Access to other remote resources such as files, and Microsoft SQL Databases have been unaffected by this change.

After working with Microsoft support on the issue for several weeks.  We have been informed that we will need to store Windows Credentials securely ourselves, and use them in conjunction with LogonUser / Impersonate as needed when working with Remote Queues.  

Historically we have preferred to not store or have access to Windows Credentials, and are posting here in hopes of resolving the issue in future updates.
Sign in to post a comment.
Posted by Microsoft on 6/27/2012 at 6:45 PM
This is by design for ASP.Net impersonation. From the msdn article (

The configuration illustrated in the example enables the entire application to run using the contoso\Jane identity, regardless of the identity of the request. This type of impersonation can be delegated to another computer. That is, if you specify the user name and password for the impersonated user, you can connect to another computer on the network and request resources, such as files or access to SQL Server, using integrated security. If you enable impersonation and do not specify a domain account as the identity, you will not be able to connect to another computer on the network unless your IIS application is configured to use Basic authentication.

Simply ASP.NET application that is running cannot authenticate to the remote printer as impersonation does not work with anonymous access, unless you use impersonation credentials.
Posted by Bin [MSFT] on 6/19/2012 at 1:18 AM
Thank you for submitting feedback on Visual Studio 11 and .NET Framework. Your issue has been routed to the appropriate VS development team for review. We will contact you if we require any additional information.
Posted by Macy [MSFT] on 6/18/2012 at 5:53 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(