emeriks
Goto Top

Windows 10 - Probleme mit Point-And-Print

Hi,
wir kämpfen z.Z. mit einigen Druckertreibern, welche unter Win10 beim Verbinden eines Druckers von Printserver mit dem Dialog kommen: "Vertrauen Sie diesem Drucker?", wenn der Treiber noch nicht auf dem PC installiert ist.

"Point-And-Print-Einschränkungen" über GPO deaktivieren, das ignorieren diese Win10 Rechner. Es gibt dazu auch einen etwas älteren Hinweis von Microsoft: MS16-087: Security update for Windows print spooler components: July 12, 2016

Es betrifft nur Treiber, welche "kein Paket sind". (Was auch immer das eigentlich bedeutet.)

Wir haben zwar im Web Hinweise gefunden, dass man auf dem Printserver einfach in der Registry an den Treiberwerten das "PrinterDriverAttributes" auf einen ungeraden Wert setzen soll (Bit 0 auf 1 setzen). Aber erstens muss es doch einen Grund geben, warum diese Treiber "kein Paket" sind und zweitens kann es doch nicht ernsthaft sein, dass man auf allen Printservern bei allen betreffenden Treibern erst so manipulieren muss, damit das funktioniert.

Also habe ich mit den GPO getestet und doch tatsächlich einen Setup gefunden, mit welchem das funktioniert. Etwas irre, aber was soll's ...

Stand heute (2018-07-19)
Win 10.0.16299.547

Man kann es auch "regulär" lösen, ohne die Treiber zu "hacken":

GPO
"Point-and-Print-Einschränkungen" --> aktivieren
"Beim Installieren von Treibern für eine neue Verbindung:" --> "Warnung oder Anhebungsaufforderung nicht anzeigen"
"Beim Aktualisieren von Treibern für eine vorhandene Verbindung:" --> "Warnung oder Anhebungsaufforderung nicht anzeigen"
"Benutzer können Point-and-Print nur mit folgenden Servern verwenden:" --> "Aktiviert"

Jetzt kommts! face-wink
"Vollqualifizierte Servernamen eingeben (durch Semikolons getrennt)" --> server.domain.tld;server

Bei uns funktioniert das nur dann (und nur genau dann! ), wenn man hinter dem FQDN des Printservers auch noch dessen NetBIOS-Namen schreibt (Semikolon-getrennt). Und auch nur in dieser Reihenfolge: FQDN;NetBIOS. Anders herum kommt prompt die Meldung, dass eine Richtlinie das Verbinden des Druckers nicht erlauben würde.

Wenn es mehrere Printserver sein sollen, dann so: server1.domain.tld;server1;server2.domain.tld;server2;server3.domain.tld;server3

Dieses Verhalten habe ich heute in einem langen, ausgiebigen Testszenarion durchgespielt, mit Gegenprobe und Reproduktion.

E.

PS: Sollte das ein alter Hut sein, dann kommentiert bitte mit entsprechendem Link. Danke!

Content-ID: 380762

Url: https://administrator.de/contentid/380762

Ausgedruckt am: 25.11.2024 um 01:11 Uhr

Th0mKa
Th0mKa 20.07.2018 um 10:16:42 Uhr
Goto Top
Zitat von @emeriks:

Wir haben zwar im Web Hinweise gefunden, dass man auf dem Printserver einfach in der Registry an den Treiberwerten das "PrinterDriverAttributes" auf einen ungeraden Wert setzen soll (Bit 0 auf 1 setzen). Aber erstens muss es doch einen Grund geben, warum diese Treiber "kein Paket" sind und zweitens kann es doch nicht ernsthaft sein, dass man auf allen Printservern bei allen betreffenden Treibern erst so manipulieren muss, damit das funktioniert.

Der Treiber muß halt Package Aware sein. Besorg dir vom Hersteller einen passenden Treiber und deine Probleme verschwinden.

/Thomas
emeriks
emeriks 20.07.2018 um 10:39:22 Uhr
Goto Top
Der Treiber muß halt Package Aware sein. Besorg dir vom Hersteller einen passenden Treiber und deine Probleme verschwinden.
Wenn das so einfach wäre, dann würden auch andere keine Probleme damit haben.
Erstens gibt es nicht für alle Drucker solche Treiber und zweitens kommt es vor, dass solche Treiber u.U. nicht das gewünschte Druckergebnis haben. Wir z.B. haben hier sehr viele Anwendungen, deren Einstellungen und die der Drucker aufeinander abgestimmt werden müssen. Wenn man da erst einmal validierte und freigebene Setups hat, dann können die Basis-Admins für die Printserver nicht einfach mal so einen Treiber austauschen. Gleiches gilt für die Druckermodelle, welche die Treiber implizieren.
Th0mKa
Th0mKa 20.07.2018 um 10:53:26 Uhr
Goto Top
Zitat von @emeriks:

Wenn das so einfach wäre, dann würden auch andere keine Probleme damit haben.

Es ist halt seit KB3170455 eine Voraussetzung zur Installation von Druckertreibern als Nicht-Administrator, und da KB3170455 ein Sicherheitsupdate war muß man sich da jetzt halt mit den Auswirkungen eine Weile rumschlagen. Im Grunde hätte man bei der Beschaffung aber schon seit 10 Jahren darauf achten sollen das die Druckertreiber Package Aware sind.
diemilz
diemilz 30.07.2018 um 06:01:17 Uhr
Goto Top
Moin,

diese Vorgehensweise kann ich bestätigen, allerdings gilt das bei uns auch mit Windows 7. Wir haben die GPO 1:1 genau so konfiguriert. Würden wir das nicht machen, dann hätten wir die gleiche Meldung bei allen Windows 7 PCs.

Gruß

Stephan
emeriks
emeriks 30.07.2018 um 08:25:23 Uhr
Goto Top
Zitat von @diemilz:
Danke fürs Feedback.
Allerdings - Ich kann jetzt nicht schwören, ob Drucker mit betreffenden Treibern bei uns auch am Win7 verwendet werden. Mir ist jedenfalls kein Win7-Fall bei uns bekannt.
chgorges
chgorges 03.08.2018 aktualisiert um 11:33:37 Uhr
Goto Top
Kann ich so nur bestätigen, allerdings war das KB3170455 nicht ganz der Auslöser.

Mit MS16-087 hat es bei Windows 7 und Windows 10 gereicht, die GPO "Point-and-Print-Einschränkungen" auf "Deaktiviert" zu lassen, so lange man aber V4-Druckertreiber eingesetzt hat.

Microsoft hat letzt Jahr im Sommer (ca. zwischen August und Oktober) das KB3170455 in V2 (hinterrücks) über die CUs nochmal verteilt. Seit der Aktion muss man die GPO ausführlich aktivieren und mit Informationen befüllen, egal ob man Win7, Win8 oder Win10 einsetzt.

Hier ist die GPO nochmal bildlich veranschaulicht.
mayho33
mayho33 25.02.2019 um 11:33:24 Uhr
Goto Top
Ist zwar schon etwas Off-Topic, aber....

...Für mich hört sich das an als wäre der Treiber zwar installiert, aber nicht signiert. Ein Treiber dieser Art sollte sollte mindestens aus einer INF-Datei und einer CAB-Datei bestehen in der das gültige Zertifikat eines vertrauenswürdigen Herausgebers enthalten ist. Windows 10 verweigert eigentlich unsignierte Treiber. Manchmal unterlaufen aber auch namhaften Herstellern (lol MS) kleinere Fehler.

Hatte ein ähnliches Problem mit Treibern für einen via USB angeschlossenen Monitor. Die Lösung: Zur Installations-Zeit die Treiber per Machine signieren.

Extrem aufwändig aber manchmal notwendig:

Du brauchst:
Windows 10 SDK: https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk
W10 WDK: https://docs.microsoft.com/en-us/windows-hardware/drivers/download-the-w ...

Nach diesem Bsp. aus meiner CMD findest du die notwendigen Tools (einfach weg kopieren inkl. der Abhängigkeiten)
Set CDIR=%~dp0
IF %CDIR:~-1%==\ SET CDIR=%CDIR:~0,-1%

"%~dp0makecert.exe" -r -n CN="IRTOUCH SYSTEMS" -ss IRTOUCH -sr LocalMachine  
"%~dp0certutil.EXE" -store IRTOUCH "IRTOUCH SYSTEMS" "%~dp0IRTOUCH.cer"  
"%~dp0certmgr.exe" -add -all -c "%~dp0IRTOUCH.cer" -s -r localmachine root  
"%~dp0certmgr.exe" -add -all -c "%~dp0IRTOUCH.cer" -s -r localmachine trustedpublisher  
"%~dp0inf2cat.exe" /os:10_X64 /driver:"%CDIR%"  
"%~dp0signtool.exe" sign /s IRTOUCH /sm /n "IRTOUCH SYSTEMS" "%~dp0tucusb.cat"  
pnputil -i -a "%~dp0TucUSB.INF"  


Grüße!