IPP driver package not created in a clustered print server

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

We are setting up a clustered print server, where all nodes are Win 2003 R2
EE.
Clients will connect using IPP connection over HTTP.
The problem is that when client tries to connect to a printer through
browser, the server does not create the printer driver package (.webpnp) for
the client to download. Instead the client gets a message:
--
Printer Installation Failed

The driver files are not available for the current CPU platform. Please
contact your administrator to install proper driver files on the server.
--

Then if the client connects to a printer which is created in a cluster node
(ie. not in the clustered spooler) the driver package is created and
downloaded by the client.

What I have found out so far is that package is created by a http request
similar to: http://server/printers/shared_printer/.printer?createexe&84017664
and put to /printers/PrtCabs -folder on the server.
Running the request manually behaves like a client:
-using a clustered printer the package is not created.
-using a node printer creates the package.

I have tried this in two different clusters: one 1-node and one 2-node; and
both behave exactly the same
Is there some special configuration that must be done to get this to work?

Thanks,
Jari
 
we've the same problem too- looks like combination of R2 & printcluster
problem.
but sadly no sollutions found yet about this.

we'll contact microsoft about this.
 
Hi

We did some digging around ourselves and found out that it has to do with
the security settings in Internet Explorer on the clients workstation!!!!

On the workstations you will have to add the printserver website(s) to the
local intranet zone which has a medium/low security level:

So:
- Internet Explorer
- Tools
- Internet Options
- Security
- Local Intranet
- Sites
- Add this Web site to the zone
- Add button
Fill in your printserver website(s) where your clients connect to.

When you close Internet Explorer then open a new one and go to your
printserver website you will see that you can connect to your printer and
install the drivers on the client workstation.


By the way: this also cures the lack of a "Connect" button on the printer
page....
 
Any other ideas. We have a Windows 2003 SP1 print server cluster. We have
the exact same issue but our IE settings are correct.
 
No sorry- we dont have yet found THE sollution. changing internet security
settings will not resolve the issues completly.

and still quiet, nothing heared from microsoft about this matter- we're not
the only one...

note: we experience this problem, printserver in an active directory, and
workstations are in this issue only in workgroup. but they seem to want to
authenticatie to the printserver- and thats we dont want.

we want to service printers to non-domain workstations. workstations in a
domain dont have this problem.

anyone have more ideas to resolve this???
 
All drivers are installed ofcourse on all nodes. This happens automaticly
when you fail over the server to another node. That's not the problem.

The problem is that workstation that are NOT part of the domain of the print
server cluster cannot get the drivers from the active printserver.
In IIS you set the account IUSR_[Server_name] to use for anonymous access to
the printerdrivers. But the non-domain workstations cannot get access via
this account. In the Event Log you can see that the workstation fails to get
it via the IUSR account and then tries to authenticate with its own local
username wich ofcourse fails.

Only when you enable the guest account on the active print server node the
non-domain workstations can get the printer drivers. But that is ofcourse not
the way it should be working!

This only happens on a cluster (Windows 2003 EE R2 UK). On a single machine
printserver it works fine....




Alan Morris said:
Yes make sure the drivers for the printers are installed on each node.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no rights.

NSter said:
No sorry- we dont have yet found THE sollution. changing internet security
settings will not resolve the issues completly.

and still quiet, nothing heared from microsoft about this matter- we're
not
the only one...

note: we experience this problem, printserver in an active directory, and
workstations are in this issue only in workgroup. but they seem to want
to
authenticatie to the printserver- and thats we dont want.

we want to service printers to non-domain workstations. workstations in a
domain dont have this problem.

anyone have more ideas to resolve this???
Click to expand...
Click to expand...
 
No the drivers are install for the virtual machine

Open the printers folder on the node. File Server Properties
Drivers tab

add the drivers here.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no rights.

NSter said:
All drivers are installed ofcourse on all nodes. This happens automaticly
when you fail over the server to another node. That's not the problem.

The problem is that workstation that are NOT part of the domain of the
print
server cluster cannot get the drivers from the active printserver.
In IIS you set the account IUSR_[Server_name] to use for anonymous access
to
the printerdrivers. But the non-domain workstations cannot get access via
this account. In the Event Log you can see that the workstation fails to
get
it via the IUSR account and then tries to authenticate with its own local
username wich ofcourse fails.

Only when you enable the guest account on the active print server node the
non-domain workstations can get the printer drivers. But that is ofcourse
not
the way it should be working!

This only happens on a cluster (Windows 2003 EE R2 UK). On a single
machine
printserver it works fine....




Alan Morris said:
Yes make sure the drivers for the printers are installed on each node.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no
rights.

NSter said:
No sorry- we dont have yet found THE sollution. changing internet
security
settings will not resolve the issues completly.

and still quiet, nothing heared from microsoft about this matter- we're
not
the only one...

note: we experience this problem, printserver in an active directory,
and
workstations are in this issue only in workgroup. but they seem to
want
to
authenticatie to the printserver- and thats we dont want.

we want to service printers to non-domain workstations. workstations
in a
domain dont have this problem.

anyone have more ideas to resolve this???

:

Any other ideas. We have a Windows 2003 SP1 print server cluster. We
have
the exact same issue but our IE settings are correct.

:

Hi

We did some digging around ourselves and found out that it has to do
with
the security settings in Internet Explorer on the clients
workstation!!!!

On the workstations you will have to add the printserver website(s)
to
the
local intranet zone which has a medium/low security level:

So:
- Internet Explorer
- Tools
- Internet Options
- Security
- Local Intranet
- Sites
- Add this Web site to the zone
- Add button
Fill in your printserver website(s) where your clients connect to.

When you close Internet Explorer then open a new one and go to your
printserver website you will see that you can connect to your
printer
and
install the drivers on the client workstation.


By the way: this also cures the lack of a "Connect" button on the
printer
page....
Click to expand...
Click to expand...
Click to expand...
 
Yes we know that.
All the used printer drivers are in place on the virtual machine.

Like I said earlier:
The problem is that workstation that are NOT part of the domain of the print
server cluster cannot get the drivers from the active printserver. In IIS you
set the account IUSR_[Server_name] to use for anonymous access to the
printerdrivers. But the non-domain workstations cannot get access via this
account. In the Event Log you can see that the workstation fails to get it
via the IUSR account and then tries to authenticate with its own local
username wich ofcourse fails.

It is not a problem for workstations that are part of the domain. The
printer drivers are rolled out to those workstations just fine when you click
"connect".




Alan Morris said:
No the drivers are install for the virtual machine

Open the printers folder on the node. File Server Properties
Drivers tab

add the drivers here.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no rights.

NSter said:
All drivers are installed ofcourse on all nodes. This happens automaticly
when you fail over the server to another node. That's not the problem.

The problem is that workstation that are NOT part of the domain of the
print
server cluster cannot get the drivers from the active printserver.
In IIS you set the account IUSR_[Server_name] to use for anonymous access
to
the printerdrivers. But the non-domain workstations cannot get access via
this account. In the Event Log you can see that the workstation fails to
get
it via the IUSR account and then tries to authenticate with its own local
username wich ofcourse fails.

Only when you enable the guest account on the active print server node the
non-domain workstations can get the printer drivers. But that is ofcourse
not
the way it should be working!

This only happens on a cluster (Windows 2003 EE R2 UK). On a single
machine
printserver it works fine....




Alan Morris said:
Yes make sure the drivers for the printers are installed on each node.

--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no
rights.

No sorry- we dont have yet found THE sollution. changing internet
security
settings will not resolve the issues completly.

and still quiet, nothing heared from microsoft about this matter- we're
not
the only one...

note: we experience this problem, printserver in an active directory,
and
workstations are in this issue only in workgroup. but they seem to
want
to
authenticatie to the printserver- and thats we dont want.

we want to service printers to non-domain workstations. workstations
in a
domain dont have this problem.

anyone have more ideas to resolve this???

:

Any other ideas. We have a Windows 2003 SP1 print server cluster. We
have
the exact same issue but our IE settings are correct.

:

Hi

We did some digging around ourselves and found out that it has to do
with
the security settings in Internet Explorer on the clients
workstation!!!!

On the workstations you will have to add the printserver website(s)
to
the
local intranet zone which has a medium/low security level:

So:
- Internet Explorer
- Tools
- Internet Options
- Security
- Local Intranet
- Sites
- Add this Web site to the zone
- Add button
Fill in your printserver website(s) where your clients connect to.

When you close Internet Explorer then open a new one and go to your
printserver website you will see that you can connect to your
printer
and
install the drivers on the client workstation.


By the way: this also cures the lack of a "Connect" button on the
printer
page....
Click to expand...
Click to expand...
Click to expand...
 
Any resolution yet with IPP

We have the same problem on a Single Windows Enterprise 2003 Server. Local domain systems can attach and print using IPP with out problem. Any machines outside the domain get this error. Even after authenticating.

"The driver files are not available for the current CPU platform. Please
contact your administrator to install proper driver files on the server."

And yes, we have checked everything over-and-over again, including ie security settings. Still does not work.
 
Back
Top