Internet Printing Protocol (IPP), Legacy Windows & 64-bit Windows Server
The Internet Printing role service in Windows Server 2008R2 is under the Print and Document Services role, and has a requirement of the IIS service (with ASP) to function.
What it provides is a method to install "web printer connections" on client machines via HTTP, including pacakging the print driver and downloading it from the web server.
Reference:
https://msdn.microsoft.com/en-us/library/ms817904.aspx
The basic principle is the client machine uses a web browser to request an ASP page on the web server which renders an HTML page based on installed & shared printers available for connection.
The list of printers is diplayed with the fields: Name, Status, Location, Jobs, Model and Comment.
The Name of each printer is a hyperlink which brings up a detailed view of that specific printer, including a summary of its print jobs and a list of actions for the printer or selected document.
Under "Printer Actions" is the "Connect" hyperlink which kicks of the web printer connection installation, and here is where our cautionary tale begins...
On clicking the link, the client and server communicate and the following actions take place:
If the client has an in-box driver for that model...
- It is installed from the local driver store on the client, no download is required
If the client does not have an in-box driver for that model...
- If the server has note already built a webpnp package for that printer, one is built now
- It is requested as a regular HTTP download by the client
- The printer driver pacakge is installed
Finally...
- The client craetes a printer port with the URL for that specific printer
In the case of in-box drivers, there is no need for the server to have the package in the architecture of the client machine.
i.e.
A Windows 7 x86 client can install a web printer connection from a Windows Server 2008R2 server for any in-box driver, as they have the same driver store
In the case of OEM driver packages, the package needs to be bundled by the server on demand, so it would need the client architecture version of the driver package to give it to the client machine.
This is where a bit of a difference comes in, depending on the client Windows version...
For Vista and later, the pre-compiled printer driver package can be given directly to the client and installed - this goes for x86 and x64 clients alike.
For pre-Vista versions of Windows, the server parses the .INF file in order to build a compatible (unsigned) driver package for the client to download and install.
| In a recent case I had, installing an OEM printer driver through IPP was working fine for Windows 7 clients, but failing on XP clients, which immediately received "Printer Installation Failed" with the cryptic message "Error Code = E0000102".
As a generic error this code translates to WAIT_TIMEOUT (actually just the last 0x102 bit) - which does not make sense as the error is thrown instantly. Using Process Monitor on the server to try to get some clues, comparing the working (Windows 7 x86 client) scenario with the failing (XP x86 client), nothing showed up as immediately obviously wrong with a registry or file I/O. So I took a time travel trace (TTT, also known as iDNA) of the IIS worker process (w3wp.exe) as the client request was being processed. Using private debug symbols, What I found was that the correct .INF file was successfully opened (the folder under C:\Windows\System32\DriverStore\FileRepository contained " _x86_neutral"), but when it was being parsed we were getting this error thrown. The error is actually from SETUPAPI, and translates to ERROR_LINE_NOT_FOUND. What I discovered was that the installer was looking first for a section named "SourceDisksNames.amd64", and not finding it (as expected, this is after all an x86 .INF file), but then also failing to locate one named "SourceDisksNames". It actually retries 5 times to find either of these sections, always getting 0xE0000102. Looking at the .INF file manually, it was indeed correct - there was only the section named "SourceDisksNames.x86" there - so why do we not look for this? SETUPAPI will use the architecture of the local machine, and as this code is running on W2K8R2, this will search for the 64-bit section first. (Similarly, if the client had been 64-bit and the server 32-bit, the same problem would be seen.) Reference: https://msdn.microsoft.com/en-us/library/ff547478(VS.85).aspx To work around this problem, I edited the .INF file before installing the package on the server, and renamed "SourceDisksNames.x86" to "SourceDisksNames". The next installation of the web printer connection from an XP client worked straight away. |
NOTE:
If you find that you are having problems installing a web printer connection on Windows Vista and later clients, then you might want to check this out...
Windows Vista introduced the security feature "Protected Mode", which Internet Explorer is able to use as it leverages the Internet security zones, where a resource is tagged with its origin.
You have problably seen the warning box appear when launching a .EXE downloaded via IE - the text tells you the file "came from the Internet" and gives you the option to unblock it permanently.
Reference:
https://msdn.microsoft.com/en-us/library/bb250462(v=vs.85).aspx
As installing a driver is definitely something you would only want to do from a trusted source, and Protected Mode is enabled for the (default) Internet zone, the host (IPP server) needs to be in one of the more trusted security zones - either Intranet or Trusted Sites.
(The other option is to temporarily disable Protected Mode for the Internet zone, but I do not recommend doing this.)
Additionally, if you are using authentication on the IIS server, have the user check the box "Remember my password" when they first connect, to see if it helps.