[English]Unter Windows kommt es ja immer wieder zu Problemen, dass Drucker nach Updates nicht mehr gefunden werden oder nicht mehr funktionieren. Ich habe zahlreiche Artikel zu diesem Thema in wechselnden Variationen dazu im Blog veröffentlicht. Ein Blog-Leser hat mich kontaktiert, weil er einen einzigen Grund für die vielfältigen Druckerprobleme im Netzwerk sieht. Er schiebt die Fehler auf die Nutzer und Administratoren, die die Drucker falsch einbinden. Ich bereite das Thema mal hier im Blog auf.
Anzeige
Problem 1: Falsche Druckereinbindung
Es kommt immer wieder vor, dass Leser oder Administratoren feststellen, dass Netzwerkdrucker unter Windows in der Geräteliste verschwinden oder plötzlich nicht mehr für Druckaufträge verfügbar sind. Der ungenannt bleiben wollende Blog-Leser sieht als Grund für den ganzen Ärger im Umfeld der Netzwerkdrucker bei den Nutzern bzw. Administratoren. Seine Aussage: "(Netzwerk-)Druckerprobleme haben ihren Ursprung im Grunde einer einzigen Tatsache geschuldet, für die Microsoft streng genommen nichts kann".
Varianten zur Druckereinbindung
Der Leser schreibt, dass die Drucker seiner Beobachtung nach schlicht falsch in Windows eingebunden werden. Netzwerkdrucker lassen sich unter Windows auf folgende Arten einbinden:
- Falsch: \\Servername\Druckername
- Richtig: \\Servername.ad.local\Druckername
Die erste (falsche) Variante verwendet üblicherweise den Namen des Printservers. Die zweite (richtige) Variante bindet den Netzwerkdrucker über den Fully Qualified Domain Name (FQDN) ein.
Warum das relevant ist
Der Leser schrieb, dass es zu Problemen führe, wenn der falsche Weg über die Einbindung per Printserver-Namen erfolge. Insbesondere wenn man die Sicherheitsvorkehrungen der vergangenen Jahren aktiviert oder diese irgendwann durch MS aktiviert werden, sei dann Ärger vorprogrammiert (RPC, SMB-Hardening, Protokollanpassungen, Kerberos-Anbindung etc.).
Anzeige
Der Leser merkt an, dass es im Netz zahlreiche Tipps gebe, wie man die Vorkehrungen wieder umgehen kann. Was aber eigentlich Quatsch sei, da man ja Löcher in die Sicherheit reißt und die Lösungen eh nicht von Dauer sind.
Der Hintergrund: Kerberos
Der Grund für die anhaltenden Netzwerkdruckerprobleme bei "falscher" Einbinden ist simpel, so der Leser. Kerberos und fast alle neueren Sicherheitsfunktionen brauchen eigentlich eine FQDN und werden auf Kerberos ausgerichtet. Microsoft habe zwar diverse Workaround eingebaut, um die Eingabe von Netzwerk-Druckserver-Namen zu unterstützen, schrieb der Leser. Denn das Unternehmen habe festgestellt, dass die meisten Nutzer damit überfordert seien, Netzwerkdrucker sauber einzubinden.
Die Kommunikation soll ja weiter über NTLM funktionieren, selbst wenn es eigentlich deaktiviert wurde. Aber das funktioniert eben nicht zuverlässig, schrieb der Leser. So eingerichtete Netzwerkdruckverbindungen seien oft grottenlahm und die Verwendung der erwähnten Workarounds sei im Grunde auch nicht Sinn der Sache.
Problem: Zu viele bereits eingerichtete Geräte
Das Problem, so die Beobachtung des Lesers: Es gibt teilweise sehr viele bereits verbundene Drucker, sowohl auf User- als auch auf Computer-Ebene. Die Benutzer gäben leider so gut wie nie eine FQDN ein, um auf einen Printserver zuzugreifen, ist die Beobachtung des Blog-Lesers. Sein Tipp wäre, Netzwerkdrucker immer auf User-Ebene zu verbinden, und auf Computerebene verbundene Drucker raus zu werfen. Auch diese Verbindungen machten oft schon Ärger, so die Beobachtung.
Problem 2: Doppelt eingerichtete Geräte
Der Blog-Leser wies mich auf ein zweites Problem hin: Wird der gleiche Drucker einmal per Name und einmal per FQDN verbunden, dann komme nicht jede Funktion/Auflistung damit klar. Denn teilweise wird der gleiche Eintrag verwendet. Das wurde, laut Leser, von Microsoft mit der Zeit etwas verbessert. Aber dieser Ansatz funktioniert halt auch nicht zuverlässig. Insbesondere auf Terminalservern wo gleichzeitig auf einer Maschine gearbeitet wird, gibt es immer wieder Probleme, hat der Leser beobachtet.
Sein Lösungsansatz: Auf dem Desktop eine Verknüpfung zum Printserver als FQDN einrichten. Seither habe er in allen Umgebungen keine Probleme mehr, schreibt der Leser. Er merkt an, dass er ganz klassisch mit Login-Scripts arbeite, um die üblichen Drucker einer Abteilung zu verbinden. Damit gebe es am wenigsten Ärger.
Microsoft lässt sich hier wohl nur eine katastrophale Kommunikation und das Fehlen entsprechender Empfehlungen vorwerfen. Der Leser schrieb, dass er es eigentlich begrüßen würde, wenn man technisch irgendwie per GPO verhindern könnte, dass eine Verbindung mit einem reinen Netzwerkdrucker-Namen eingerichtet werden kann. Aber wie das funktionieren könnte, ist unbekannt. Wie seht ihr den Sachverhalt? Stichhaltig, oder nicht belegt?
Anzeige
Ich stelle mir die Frage, was passiert, wenn man den Drucker per GUI einbindet:
Startmenü -> Geräte und Drucker -> Drucker hinzufügen.
Dann wird das AD nach freigegebenen Druckern gescannt und man wählt einen in der Liste aus.
Wie wird der Drucker dann eingebunden?
Mit oder ohne FQDN?
Afaik ohne FQDN.
Das Einbinden per GUI ist auf jeden Fall der Weg, den normale Benutzer wählen würden.
Wenn der Admin das sauber im AD mit FQDN hinterlegt hat, dann wird auch der FQDN verwendet. Hat aber z.T. auch mit den DNS/IP Einstellungen zu tun.
sowie Zertifikaten
Der Default von MS macht es an der Stelle dann aber auch schon falsch. Wenn ich in der Druckverwaltung auf dem Printserver bei einem Drucker "im Verzeichnis freigeben" anhake, dann steht da auch kein FQDN drin. Da steht dann nur an . Und das ist wie schon R.S. schrieb die Variante, die von den Nutzern über "Drucker hinzufügen" auch verwendet wird, falls die mal einen Drucker brauchen, den die nicht per GPO bekommen haben. Benötigt ja auch keine Adminrechte zum Einrichten.
Anscheinend mag die Kommentarsoftware bestimmte Sonderzeichen nicht. Der Satz "Da steht dann nur an" sollte "Da steht dann nur Druckername an Printserver" heißen, ich hatte Druckername und Printserver aber jeweils in Pfeilklammern geschrieben und das wurde rausgefiltert.
Hi…
Das kommt wohl daher, dass die Blog-Software die Pfeilklammer als Einleitung eines HTML-Tags interpretiert.
Da muß man sich was anderes ausdenken, bspw. mithilfe eben jener Tags Text zu formatieren, wie bspw. mit "b" für fett und "i" für kursiv.
Da ich da nie Probleme hatte, kann ich da nicht viel zu sagen… mal eben nachgesehen, sind alle per FQDN eingebunden. Das Ausbleiben von Fehlern spricht dafür, aber wie gesagt nicht weiter damit beschäftigt. Wieso auch wenn alles funzt, denke mal intuitiv alles richtig gemacht ;-P
Drucker (und auch Freigaben) werden hier grundsätzlich per GPO eingebunden, wobei ggf die Verbindung auch gelöscht und neu angelegt (und nur nicht nur aktualisiert) wird.
Bisher gab es damit keine Probleme.
Verbindungen per Kurzname entstehen meist durch schlampige Benutzereingaben (\\server\freigabe) und können für alle Sorten von Problemen verantwortlich sein, insbesondere wenn sie je nach Standort des Nutzers (z.B. Homeoffice) unterschiedlich aufgelöst werden.
Grundlegend ist FQDN bei allem der bessere Weg – also auch z.B. Netzwerkfreigaben. Da wird u.a. bei DFS auch gerne auf NetBIOS gewechselt…
Ansonsten, man kann über GPO Netzwerkdrucker auf verschiedene Arten verwalten. Zum einen kann man diese direkt (z.B. je nach Sicherheitsgruppe) zuweisen lassen. Zum anderen kann man nur bestimmte Verbindungen erlauben. Dann ist die Verbindung exakt nur zu diesen Druckern möglich. Ist aber schon lange her, wo wir das eingerichtet hatten…
…da sowieso die Drucker via GPO verteilt werden, gibt es mittlerweile niemanden mehr, der hier manuell einen Drucker (via AD) suchen und zuweisen würde.
…wie zuvor Luzifer geschrieben hat: "Das Ausbleiben von Fehlern spricht dafür, aber wie gesagt nicht weiter damit beschäftigt."
also in der Letzten Firma wo ich tätig war als Administrator wurden die Drucker dem User per AD zugewiesen und das bei einem unternehmen von mehr als 1500 Mitarbeitern und gefühlt 300 Druckern. Das war echt mühselig, Vorschläge sie per GPO zu verteilen wurde immer wieder abgewiesen. Aber so ist das halt wenn man das schon seit Jahren so macht. Zum Glück bin ich dort nicht mehr.
Seit Windows NT mit Anmeldescript per "rundll32 printui.dll,PrintUIEntry" und selbstverständlich FQDN eingebunden. Noch nie Probleme mit plötzlich fehlenden Druckern.
https://learn.microsoft.com/de-de/windows-server/administration/windows-commands/rundll32-printui
Wir drucken hier schon 10 Jahre fehlerfrei über die falsche Verbindung.
Bei uns auch. Denke das FQDN für viele derartige Probleme veranwortlich ist, aber halt nicht für alle.
michael, ich seit 20 Jahren in 3 verschiedenen Unternehmen…..
Stets über einen Printserver.
Grüßle
Zumal der Printserver das ja selber so in die GPO einträgt…
klares Jein. das ist abhängig von der verwendeten CSE der Richtlinie. bei den gpps hat du es selbst in der Hand.
bei den veröffentlichen drucken ist es ein Frage der MMC über die du arbeitest
Naja,
mir ist schon klar, dass ich das händisch über GPPS granularer einstellen kann.
Der MS Printserver haut das halt so in die GPO, daher:
Welche MMC muss ich denn verwenden, damit das nicht so ist?
Danke
Drucken über die "falsche" Verbindung, also dem NetBIOS Namen: Das funktioniert so lange wie die aktuellen Windows-Updates inkl. der durch MS geplanten Sichereits-Enforcements nicht aktiviert werden. Teilweise können die noch rückgängig gemacht werden, teilweise nicht.
Spätestens wenn das alles mal durch ist und NTLM deaktiviert wird (was man ja eigentlich möglichst rasch tun sollte wo möglich), wird das nicht mehr funktionieren. Kerberos kann nur FQDN.
Dann sollte MS es vielleicht mal in Betracht ziehen, ihre Tools auch entsprechend anzupassen, damit die es von Hause aus "richtig" machen. Bei uns werden die Drucker am Printserver angebunden und dann im AD freigegeben, damit User sich die bei Bedarf selber anbinden können. Per GPO die Drucker an die Usergruppen angebunden, die sie regelmäßig brauchen. Und wenn man die Freigabe in der Gruppenrichtlinienverwaltung dann nicht händisch einträgt, sondern über die drei Punkte aus der Suche raussucht, werden die auch schon "falsch" in der Form \\SERVER\Druckername eingetragen.
Wobei ich ebenfalls sagen muss, dass das bei uns soweit alles funktioniert.
Früher wurde ja WINS verwendet um FQDN aus Netbios-Name abzuleiten, aber das funktioniert nur innerhalb des eigenen /24 und ist daher obsolet. Den Nachfolger kennen wohl recht wenige: GlobalNames
im DNS eine gleichnamige Zone anlegen und dort zu jedem wichtigem Netbios-Namen den FQDN konfigurieren. Nicht vergessen die Unterstützung des Feature auch zu aktivieren. Keine Ahnung mehr wie der Befehl lautet…
Obwohl, hier steht ja alles:
https://learn.microsoft.com/en-us/powershell/module/dnsserver/set-dnsserverglobalnamezone?view=windowsserver2022-ps
das ist eine komplette Anleitung, die mir gut gefällt:
https://www.forsenergy.com/en-us/dnsmgr/html/acf8b192-752d-4459-b7e4-a404309fcf32.htm#:~:text=To%20help%20network%20administrators%20migrate%20to%20DNS%20for,records%20with%20single-label%20names%2C%20without%20relying%20on%20WINS.
Wenn man die Drucker per "Druckverwaltung" als GPO verteilt (Rechtsklick "Mit Gruppenrichtlinie bereitstellen"), wird stets nur der Name des Druckservers verwendet und lässt sich auch nicht ändern.
Screenshot: https://i.imgur.com/NpeHEJq.png
Die resultierende GPO kann man per GPO-Verwaltung auch nicht nachträglich anpassen.
Kennt jemand da nen Trick um hier FQDNs zu verwenden oder nutzt das sonst niemand?
GPPs verwenden, Deployed printer schlechter gemacht
>>> Microsoft lässt sich hier wohl nur eine katastrophale Kommunikation und das Fehlen entsprechender Empfehlungen vorwerfen. <<<
Sehe ich als Aussenstehender nicht so. Mein Rat: mit (1) beginnen und dann bedarfsweise und sukzessive alles durcharbeiten was sich links im Navigationsbaum unterhalb des Knotens "Printing" befindet. Zwecks besserer Orientierung: Dieser Knoten "Printing" befindet sich zwischen den Knoten "Performance" und "Remote Deskop Services".
Ausserdem: In (2) insb. das Kapitel "Directory Service Interaction" ab S. 184 durcharbeiten, sowie in den Abschnitten "1.2.1 Normative References" (S. 21) und "1.2.2 Informative References" (S. 22) gelistete Dokumente ggf. hinzuziehen. Dort ist auch (3) erwähnt; Titel: " [MS-ADOD]: Active Directory Protocols Overview". Die Grafiken auf den S. 23, 25 und 27 bieten Orientierung.
(1) learn.microsoft.com/en-us/troubleshoot/windows-server/printing/use-group-policy-to-control-ad-printer
(2) winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-RPRN/[MS-RPRN]-220429.pdf
(3) winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-ADOD/[MS-ADOD].pdf
Könnte etwas mit NetBIOS gegenüber DNS sein. Versucht Windows, wenn man keinen FQDN angibt, zuerst über NetBIOS auflösen? Und dann im zweiten Schritt per DNS (mit automatischem Anhängen der Domäne, sofern kein FQDN)?
Ich richte Netzlaufwerke und Drucker seit über 20 Jahren auch ohne AD/Domäne immer per FQDN ein und erzwinge so eine Namensauflösung per DNS. Ich hatte in den letzten Jahren keinerlei Probleme mit Druckern! Früher gab es ohne FQDN immer mal wieder Probleme weil die Namensauflösung unter Windows per NetBIOS gemacht wurde, heute kann da aber auch mDNS reinspielen. Windows Systeme sind jetzt ja auch mit %COMPUTERNAME%.local in lokalen Netz erreichbar. Klar braucht man einen lokalen DNS Server aber zur Not tut es dafür auch ein Router mit OpenWRT oder eben der DNS Server auf der Firewall.
Neuer Angriffsvektor auf Windows-Systeme mit *.MSC Dateien (mmc.exe Snapins) per ungepatchter Lücke in Windows.
https://www.bleepingcomputer.com/news/security/new-grimresource-attack-uses-msc-files-and-windows-xss-flaw-to-breach-networks/
Was hat das mit den o. g. Druckproblemen zu tun?
Egal, jetzt kannst du nicht mehr behaupten, von nichts gewusst zu haben.
Ps.: Hast du eigeltlich mal geschaut, wieviele der Lesertipps an den Hausmeister auf mich zurück gehen?
Und das berechtigt Dich seit wann genau zum Missbrauch der Kommentarfunktion völlig themenfremder Blogeinträge?
Wir arbeiten schon seit vielen Jahren mit Druck- und Fileserver ohne FQDN.
Also so in der Art:
\\druckserver\drucker
\\fileserver\freigabe
Bislang überhaupt keine Probleme.
Die Benutzer verbinden ihre Drucker selbst, indem sie im Windows-Explorer auf \\druckserver gehen und dann beim gewünschten Drucker Rechtsklick –> "Verbinden…" anklicken.
Keinerlei Probleme bisher, weder mit den Druckern noch mit den Freigaben.
BTW – weil hier manche Kommentare "Netzlaufwerke" erwähnen:
Mit Netzlaufwerken arbeiten wir nur bei DATEV, weil DATEV das unbedingt benötigt.
Ansonsten zum Glück keine Netzlaufwerke. Mit Netzlaufwerken habe ich in vorherigen Firmen immer nur Probleme erlebt. Weil Windows die nicht zuverlässig verbindet, oder irgendwann die Verbindung verliert. Ein Glück, dass es heutzutage kaum noch Software gibt, die unbedingt Netzlaufwerke benötigt. Sowas wäre für mich ein Grund, die Software nicht zu kaufen!
Bei den DATEV-Benutzern stellen wir über das Login-Script im AD sicher, dass das Netzlaufwerk verbunden wird.
Bei homogenen Netzwerken sehe ich da auch eher weniger Probleme. Da ich aber schon ewig auch Nicht-Wintendo-Systeme im Netzwerk habe, habe ich mir recht früh angewöhnt, mit FQDN zu arbeiten. Netzlaufwerke werden per GPO verteilt, ebenfalls problemlos.
Mh, hiermit oute ich mich als Laie! Ich verstehe nur Bahnhof!
Mein Netzwerkdrucker habe ich mithilfe des Treibers eingerichtet.
Der hängt direkt an der Fritte und ihm wurde eine IP zugewiesen.
Auf den verschiedenen Rechnern wurde wie gesagt per Treiber der Drucker eingerichtet.
Wenn ich nun "printmanagement.msc" aufrufe, stehen (steht) unter
"Bereitgestellte Drucker" nichts! Der Netzwerkdrucker taucht unter
"Druckserver\Lokaler Rechner\Drucker" auf.
Mir ist es auch schon so ergangen, dass nach einem Update der Drucker nicht mehr da war und ich wusste mir einfach nicht zu helfen und nutzte das Druckertreibersetup um diesen Fehler zu beheben.
Später erkannte ich, dass ich einfach in der Fritte nur nachschauen muss und in den Einstellungen der Systeme die neue IP eintragen muss.
Nicht immer war das die Ursache, aber oft.
Nun aber meine Frage, hat das mit dem beschriebenen Problem zu tun?
Wenn ja, wie genau binde ich den Netzwerkdrucker dann "sicherer" ans System an?
>>> … Fritte … Fritte … Wenn ja, wie genau binde ich den Netzwerkdrucker dann "sicherer" ans System an? <<<
Ich würde es mal mit neuen Fritten versuchen.
Super Ratschlag, zumal Du gar nicht wissen kannst,
wie neu oder alt meine Fritz!Box ist.
Und, was Du auch immer damit bezwecken wolltest, es hat nichts mit der Sache
zu tun. Aber danke.
Ich nehme an, er wollte auch nur mal darauf hinweisen, dass dieser Blog hier kein Endbenutzerhilfeforum ist.
deine Drucker sind als lokale Drucker über einen ip Anschluss eingerichtet. für die Einrichtung benötigst du immer administrative Rechte
der Wunsch in der Firma ist, das es der User mit seinem rechten verbunden darf. dazu gibst du an einem System den Drucker frei und der User greift auf die Freigabe zu, wie bei einer Dateifreigabe.
beim Klick auf die Drucker Freigabe triggert der User einen System Prozess, der die Rechte zur Einrichtung hat.
… wenn die 3 Richtlinien zu printnightmare gesetzt sind
https://www.gruppenrichtlinien.de/artikel/printnightmare-3-richtlinien-werden-benoetigt
Ah, danke.
Ich glaube, ich habe es geschnackelt.
Drucker z.B. an Rechner Nr.2, Druckerfreigabe einrichten und alle anderen Rechner im Netz können dann auf diesem drucken.
Auch muss dann nicht auf jedem anderen Rechner die/der Treiber installiert werden.
Richtig?
Warum stellst Du in der Fritz!Box nicht ein, dem Drucker immer die selbe IP-Adresse zuzuteilen? Damit umgehst Du das Problem, dass er sich wegen zu langer Auszeit eine abweichende IP-Adresse zur letzten von der Box einfängt.
Kann mir einer sagen wie ich die Empfehlung ggf. per Script einrichten kann?
[…] Sein Tipp wäre, Netzwerkdrucker immer auf User-Ebene zu verbinden, und auf Computerebene verbundene Drucker raus zu werfen.
[…]
Soll heißen:
Kann man alle auf Computerebene verbundenen Drucker per Script rauswerfen?
Fall ja muss danach wahrscheinlich dran gedacht werden, dass sich der Benutzer meldet, weil er danach nicht mehr Drucken kann bzw. sein Drucker verschwunden ist?
>>> Kann man alle auf Computerebene verbundenen Drucker per Script rauswerfen? <<<
Irgendwelche Kommandos wird es schon geben; siehe in (1) links im Navigationsbaum den Bereich von "Print" bis "Pushprinterconnections". Des weiteren s. (2) alles des Musters "Remove-…" insb. "Remove-Printer".
(1) learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731623(v=ws.11)
(2) learn.microsoft.com/en-us/powershell/module/printmanagement/?view=windowsserver2022-ps
Oder man verzichtet in seinen Netzen komplett auf gammelige Windows-Clients mit Druckern und nutzt nur noch Terminalserver auf denen alle Drucker eingerichtet sind und per Gruppenzugehörigkeit nur noch der Haupt- und ein Ersatzdrucker für einen User verfügbar sind.
Immer wieder faszinierend zu sehen, wie Wald-Wiesen-Windows-Admins nach 24 Jahren die Grundlagen Ihrer AD-Netze verstehen.
Terminalserver sind nicht das Allheilmittel. Gibt auch Software, die darauf nicht vom Hersteller freigegeben ist oder auch einfach etwas mehr Ressourcen benötigt, CAD-Programme zum Beispiel. Oder spezielle Hardware drin ist für Produktionsmaschinen, auch da muss man mal drucken. Spätestens dann hat man wieder Thick-Clients, ist natürlich schön wenn man alles mit Thin-Clients und TS erschlagen kann, ist aber halt nicht überall möglich.
Und bezüglich deinem "Wald-Wiesen-Windows-Admin": Man kann mMn vom Hersteller des ADs schon verlangen, dass seine eigenen Tools es richtig machen, wenn er sie schon anbietet. Ist ja nicht so, dass die GUIs und Assistenten alle abgekündigt wären, oder?