[2008R2] HTTP Printing werkt niet op x86 client

[Verwijderd]

Ik heb een Windows 2008R2 print server.
Deze server bied zowel printers via http aan als via \\SERVER\Printer
Wanneer ik vanaf een client (x86 of x64 maakt niet uit) verbind met \\SERVER\Printer wordt netjes de driver geinstalleerd.

Wanneer ik vanaf een x86 client via http://SERVER/printers/printer de printer wil installeren lukt dit niet.
Deze geeft dan de volgende foutmelding:

Printer Installation Failed.
The printer driver is unknown.

Een x64 client gaat WEL goed.

Echter klopt de driver wel, het gaat immers via het UNC path goed.

Heeft iemand enig idee hoe dit op te lossen is?
Permissies is volgens mij niet het probleem, want als Domain Admin krijg ik ook deze foutmelding.
Wellicht een vinkje in IIS7.5 dat ik vergeten ben? Zou alleen niet weten welke.

Het maakt ook verder niet uit wat voor printer het is (Samsung/HP/OCE/Xerox) bij alle types komt deze melding via HTTP naar boven en werkt het via UNC prima.
Client maakt ook niet uit (XP/Vista/7)

[Verwijderd]

Op een test server exact hetzelfde issue.
Kan iemand dit bevesitgen? Wellicht is dit een bug in R2?

[The-Source]

Of je titel klopt niet. Of je tekst over wat wel en niet werkt klopt niet.

In de titel staat x64 werkt niet.
In de tekst X86 werkt niet en x64 weer wel

Als je eerst dat op orde hebt is het misschien wat makkelijke om te zoeken.

[Verwijderd]

Het werk niet op een x86 client via http printing.

[Verwijderd]

Niemand een idee?

[ftpfreak]

Heb je wel x86 drivers op de printserver staan?

[Verwijderd]

Ja, want zoals ik aangeef in de TS gaat het installeren van de printer via \\SERVER\PRINTER wel goed.
Op zowel een x86 als x64 client.
Het werkt alleen niet op een x86 client via http.

[Henkje.doc]

Geeft de IIS logfile nog specifieke dingen aan?.

Het lijkt wel of de bewuste X86 client niet volledige rechten heeft op de site. Neem aan dat je met dezelfde user / credentials bent ingelogd.

[Verwijderd]

Logging nog niet naar gekeken, zal ik maandag eens doen.

Zelfde user gebruikt op een x64 systeem waarbij het via http wel werkt.
Ook dezelfde user krijgt via het UNC path ook netjes de printer toegevoegd en kan dan printen.
Rechten lijken mij dus niet het probleem.

[Verwijderd]

Logs leverden niks op helaas.

[Henkje.doc]

Dan lijken authorisaties inderdaad wel uit te sluite, anders was er wel iets van 401 teruggekomen in IIS.

Mogelijk dat de x86 driver niet beschikbaar is voor het webdeel?
Nu heb ik zelf al zitten kijken of dit uberhaubt wel noodzakelijk is.

Als je de printer nogmaals uitrolt en opnieuw shared - voor de bewuste clients, zodat andere users er geen last van hebben - krijg je dan met exact dezelfde printer nog steeds dat issue?

Je zou bijna gaan denken dat de bewuste x86 driver het niet 'prettig' vindt om via IIS7 uitgerold te worden. Dat lijkt nml het enige verschil te zijn tussen de werkwijze van wel en niet functioneren.

[Verwijderd]

Dacht eerst dat dit het oplost, helaas toch niet.

Wellicht iemand anders met R2 die dit zou kunnen/willen testen?
Dat een driver via http niet zou werken wil ik niet echt geloven/accepteren.
Als het nu 1 driver was, oke. Maar het zijn wel 10+ verschillende drivers.

[ Voor 221% gewijzigd door Verwijderd op 02-02-2010 18:05 ]

[Henkje.doc]

Heb helaas hier nog geen R2 draaien in VPC, maar heb nog even gekeken in een Win2k8 en daar zie ik bij InternetPrinting een opmerking staat dat op de betreffende client wel de Internet Printing Client geinstalleerd moet zijn. Mogelijk dat hier op de betreffende werkplekken iets misgaat in combinatie met IIS7? Ontbreken zou raar zijn want dan zou je de betreffende printer helemaal niet kunnen installeren.

Ben nog op zoektocht geweest via google, maar daar kom ik veel tegen rondom het uberhaubt niet installeren van 32bit drivers onder 64 bit windows. Daarvoor dient de behorende driver in c:\windows\system32\driverStore\FileRepository te staan.

[Verwijderd]

Zijn unmanaged clients, dus het wordt lastig om die te kunnen manipuleren, mocht het de Internet Printing Client betreffen.

De drivers zijn prima geinstalleerd, dat is het vreemde juist.

[Henkje.doc]

Verwijderd schreef op dinsdag 02 februari 2010 @ 20:45:
Zijn unmanaged clients, dus het wordt lastig om die te kunnen manipuleren, mocht het de Internet Printing Client betreffen.

De drivers zijn prima geinstalleerd, dat is het vreemde juist.

Bedoel je hiermee een soort van Thin Clients? Heb met installatie van andere devices wel eens meegemaakt dat de driver dan niet meewerkt. Wat natuurlijk wel raar is dat deze dan op andere clients wel werken.

Het gaat een beetje de "zoek de tien verschillen worden", maar dat is vaak met troubleshooten een mooie manier om dingen weg te strepen.

Heb je de mogelijkheid om met een clean install X86 client de installatie na te bootsen? Mogelijk dat een vorige installatie de driver lokaal in de war schopt.

[Zwelgje]

Henkje.doc schreef op dinsdag 02 februari 2010 @ 18:46:
Heb helaas hier nog geen R2 draaien in VPC, maar heb nog even gekeken in een Win2k8 en daar zie ik bij InternetPrinting een opmerking staat dat op de betreffende client wel de Internet Printing Client geinstalleerd moet zijn. Mogelijk dat hier op de betreffende werkplekken iets misgaat in combinatie met IIS7? Ontbreken zou raar zijn want dan zou je de betreffende printer helemaal niet kunnen installeren.

Ben nog op zoektocht geweest via google, maar daar kom ik veel tegen rondom het uberhaubt niet installeren van 32bit drivers onder 64 bit windows. Daarvoor dient de behorende driver in c:\windows\system32\driverStore\FileRepository te staan.

R2 kan ook niet in VPC vpc kan geen 64bit guests aan

[Verwijderd]

Met unmanaged devices bedoel ik laptops die geen lid zijn van het domein.
Daarvoor bieden we HTTP printing aan.
Daarom is het zo belangrijk dat het 'out of the box' werkt met elke unmanaged client (wat met x64 dus wel goed gaat). Gebruiker moet niks hoeven aanpassen, moet dat wel, dan lever je een slechte dienst.

Heb uiteraard een laptop al meerdere keren voorzien van een clean install XP SP3 + alle updates, Vista SP2 + updates en Win 7 + alle updates. Maar helaas...

[Henkje.doc]

Verwijderd schreef op donderdag 04 februari 2010 @ 20:43:
Met unmanaged devices bedoel ik laptops die geen lid zijn van het domein.
Daarvoor bieden we HTTP printing aan.
Daarom is het zo belangrijk dat het 'out of the box' werkt met elke unmanaged client (wat met x64 dus wel goed gaat). Gebruiker moet niks hoeven aanpassen, moet dat wel, dan lever je een slechte dienst.

Heb uiteraard een laptop al meerdere keren voorzien van een clean install XP SP3 + alle updates, Vista SP2 + updates en Win 7 + alle updates. Maar helaas...

euh je hebt helemaal gelijk...
Virtual Box zou het wel moeten kunnen, maar dan alleen als je CPU Harware Virtualisatie ondersteund.
(...henkje heeft vandaag zijn eerste MCITP examen en is dus een klein beetje zenuwachtig....)

Verwijderd schreef op donderdag 04 februari 2010 @ 20:43:
Met unmanaged devices bedoel ik laptops die geen lid zijn van het domein.
Daarvoor bieden we HTTP printing aan.
Daarom is het zo belangrijk dat het 'out of the box' werkt met elke unmanaged client (wat met x64 dus wel goed gaat). Gebruiker moet niks hoeven aanpassen, moet dat wel, dan lever je een slechte dienst.

Heb uiteraard een laptop al meerdere keren voorzien van een clean install XP SP3 + alle updates, Vista SP2 + updates en Win 7 + alle updates. Maar helaas...

Als zelfs een Clean install op X86 clients nog problemen geeft dan lijkt het bijna wel dat die betreffende clients 'uitgesloten' zijn voor deze driver en dat de (X86) driver dan toch niet aangeboden kan worden via deze service op een 64 bits OS?. Schoner als Clean install kun je toch niet gaan. (Installatieissue's Client uitgesloten).

Probleem doet zich dus ook voor als je met een Local Admin account inlogt en dan via HTTP printing de driver gaat installeren? (Rechten issue uitgesloten)

Als je de driver handmatig installeerdt op de client en dan via HTTP printing een actie wil ondernemen werkt dat wel?

[Verwijderd]

Henkje.doc schreef op vrijdag 05 februari 2010 @ 06:50:
Probleem doet zich dus ook voor als je met een Local Admin account inlogt en dan via HTTP printing de driver gaat installeren? (Rechten issue uitgesloten)

Ja, probleem doet zich dan ook voor (zowel op XP als Win7) Ook nog getest met UAC uit in Win7, geen effect.

Henkje.doc schreef op vrijdag 05 februari 2010 @ 06:50:
Als je de driver handmatig installeerdt op de client en dan via HTTP printing een actie wil ondernemen werkt dat wel?

Nope, helaas maakt ook dat niet uit.