mcdaniels 33 Geschrieben 7. Februar Melden Geschrieben 7. Februar (bearbeitet) Hallo zusammen, ich habe ein (aus meiner Sicht) sehr ominöses Problem. Ich betreibe einen Printserver (Server 2016). Auf diesem Printserver habe ich mehrere Netzwerkdrucker freigegeben. Bei einigen meiner Windows 11 24H2 Clients (nach einem inplace Upgrade von Windows 10) geschieht nun Folgendes: Zuvor vorhandene Netzwerkdrucker verschwinden aus der Druckerverwaltung. Wenn ich versuche, den (zuvor vorhandenen) Netzwerkdrucker via \\SRV-PRN --> danach Wahl des Druckers --> Kontextmenü "Verbinden" zu verbinden, bekomme ich die Meldung "Drucker nicht vorhanden". Wenn ich dann einen beliebigen anderen vorhandenen Drucker (der noch nicht verbunden ist) zu verbinden versuche, dann funktioniert dies meist. (In dem Fall kann das auch ein komplett anderer Druckertyp sein, wie der oben erwähnte Drucker). Nach dieser Aktion ist dann plötzlich der andere verschwundene Drucker auch wieder vorhanden. Was ich bereits versucht habe: Printserver neu starten Treiber am Druckserver aktualsieren & danach neu verbinden (=Drucker nicht vorhanden) Client durchstarten Druckspooler auf Client und Server neu starten Was grundsätzlich funktioniert: Drucker via IP direkt am Client installieren. Allerdings will ich das nicht in dieser Art installieren, denn ich fahre ja über den Druckserver. Habt ihr eventuell eine Idee? Danke! bearbeitet 7. Februar von mcdaniels Zitieren
zahni 566 Geschrieben 7. Februar Melden Geschrieben 7. Februar Ich denke an den Spooler CVE https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527 Due solltest Generell auf allen Servern den Spooler deaktivieren (außer dem PrintServer). Am Client sollte es die GPO geben, dass nur lokale Verbindungen erlaubt sind. Dann gibt es noch eine GPO, die definiert, von welchem Server Treiber installiert werden dürften. Steht im Link bzw. bei Google. Ich habe jetzt keine Zeit zum Raussuchen, Zitieren
mcdaniels 33 Geschrieben 7. Februar Autor Melden Geschrieben 7. Februar (bearbeitet) Hallo @zahni ich kann dir nicht ganz folgen. Was meinst du konkret damit - bezogen auf das von mir durchgeführte Windows 11 24h2 inplace Upgrade? bearbeitet 7. Februar von mcdaniels Zitieren
zahni 566 Geschrieben 7. Februar Melden Geschrieben 7. Februar Es könnte etwas mit einer weiteren Härtung. Die Installation von Druckertreibern über diesen Weg ist seit die Bug ein Sicherheitsrisiko. Wir verbinden Drucker generell mit dem Logon-Script (und löschen sie vorher). Zitieren
mcdaniels 33 Geschrieben 7. Februar Autor Melden Geschrieben 7. Februar Okay verstehe, weshalb es dann aber auf dem von mir beschriebenen Weg läuft, ist dennoch unerklärlich, oder? Zitieren
Sunny61 816 Geschrieben 7. Februar Melden Geschrieben 7. Februar Passiert das direkt nach dem Inplace Upgrade? Falls ja, probier es mal mit W11 23H2, das 24H2 soll ja noch ein paar Fehler enthalten. Zitieren
mcdaniels 33 Geschrieben 7. Februar Autor Melden Geschrieben 7. Februar vor 15 Minuten schrieb Sunny61: Passiert das direkt nach dem Inplace Upgrade? Falls ja, probier es mal mit W11 23H2, das 24H2 soll ja noch ein paar Fehler enthalten. Jep passiert direkt danach Zitieren
Weingeist 165 Geschrieben 10. Februar Melden Geschrieben 10. Februar Tippe auch auf die Härtung. Da wurden ein paar Änderungen mittlerweile standardmässig scharf geschaltet die man vorher selber aktivieren musste. Des weiteren sollten Drucker und Netzlaufwerke nur noch mit der FQDN und nicht dem Namen verbunden werden. --> Kerberos statt NTLM. Damit das so bleibt, eine Verknüpfung des Printerservers als FQDN auf den Desktop damit sie selber neu verbinden können wenn man das nicht über Scripts löst. Am besten deinstallierst alle Treiber und wirfst sämtliche Anschlüsse und Druckerwarteschlangen von verbundenen Druckern aller User raus und verbindest die Drucker neu. Am einfachsten erzwingst das Neuinstallieren des Treibers mit einem Update auf dem Print-Server. Das erste Neuverbinden am besten als Admin. Wie stark Du das automatisierst, kommt natürlich auf die Grösse der Firma an. ;) Zitieren
mcdaniels 33 Geschrieben 10. Februar Autor Melden Geschrieben 10. Februar @Weingeist wenn es allerdings die Härtung wäre, dann würde es ja auf diesem Wege gar nicht funktionieren. Die Krux ist ja, dass der (verschwundene) Drucker nach Installation eines beliebigen anderen Druckers (auf gleichem Wege), plötzlich wieder da ist. Zitieren
Weingeist 165 Geschrieben Dienstag um 12:22 Melden Geschrieben Dienstag um 12:22 (bearbeitet) Am 10.2.2025 um 11:06 schrieb mcdaniels: wenn es allerdings die Härtung wäre, dann würde es ja auf diesem Wege gar nicht funktionieren. Die Krux ist ja, dass der (verschwundene) Drucker nach Installation eines beliebigen anderen Druckers (auf gleichem Wege), plötzlich wieder da ist. Das ist schon ein seltsames Phänomen. Allerdings wundert mich bei dem Gebastel des Druckerstacks überhaupt nichts mehr. Aber eben, seit ich die ganzen Anschlüsse, Treiber, Verbindungen etc. aus der Registry gecleant habe, anschliessend das erste mal als admin verbunden und auch die User zur Benutzung von FQDN "nötige", sind alle Probleme wie weggeblasen. Als ich mit den Härtungs-Flags rumprobiert habe als sie noch optional waren gabe es verschiedenste seltsamen Probleme. Daher würde ich erst das mal ausschliessen. MS hat viel gemacht das es irgendwie auch ohne geht und selbst mit deaktiviertem NTLM irgendwie doch manchmal mit dem Namen funktioniert. Aber eben nicht zuverlässig. (Zumindest war das so als die Flags aufkamen, weiss nicht was mit aktuellsten Updates Sache ist) Eine Frage hätte ich dazu aber noch: sprichst Du eigentlich von der richtigen Druckerauflistung oder der Geräteauflistung wo auch die Drucker drin sind? Das sind zwei komplett unterschiedliche Dinge. Die Geräteauflistung ist ziemlich buggy. Die richtige Druckerauflistung mit vernünftigen Treibern, das erste mal durch einen Admin installiert und zuverlässig per FQDN verbunden ist dagegen üblicherweise völlig unproblematisch. Treiber von Billig-Geräten verhinderten in der Vergangenheit aber gerne mal die zuverlässige Auflistung. Ich weigere mich heute sowas zu installieren. ;) bearbeitet Dienstag um 12:28 von Weingeist Zitieren
mcdaniels 33 Geschrieben Dienstag um 12:56 Autor Melden Geschrieben Dienstag um 12:56 vor 28 Minuten schrieb Weingeist: Eine Frage hätte ich dazu aber noch: sprichst Du eigentlich von der richtigen Druckerauflistung oder der Geräteauflistung wo auch die Drucker drin sind? Das sind zwei komplett unterschiedliche Dinge. Die Geräteauflistung ist ziemlich buggy. Die richtige Druckerauflistung mit vernünftigen Treibern, das erste mal durch einen Admin installiert und zuverlässig per FQDN verbunden ist dagegen üblicherweise völlig unproblematisch. Treiber von Billig-Geräten verhinderten in der Vergangenheit aber gerne mal die zuverlässige Auflistung. Ich weigere mich heute sowas zu installieren. ;) Ich hoffe ich verstehe deine Frage richtig: Ich gehe am Client auf: Systemsteuerung -> Hardware und Sound -> Geräte und Drucker Hier habe ich normalerweise von der Windows 10 Installation (vor dem Upgrade auf 11) ja Drucker angezeigt, die installiert sind. Jetzt fällt mir auf, dass z.B. nach dem Upgrade ein Drucker weg ist, der schon installiert war. Dann fängt das Spiel mit der Installiererei an, wie beschrieben. Zitieren
Weingeist 165 Geschrieben Dienstag um 17:07 Melden Geschrieben Dienstag um 17:07 Das ist genau jene die buggy ist. Da reicht ein etwas lausiger Treiber und das Ding ist falsch. Oder auch gewisse Privacy Einstellungen verhindern die korrekt Auflistung. Mit eine der dümmsten Erfindungen von MS. Die dümmste ist der eigene Druckerstack von Office. Zumindest wenn man automatisiert. Sprich es ist 0,0 relevant was da angzeigt wird ob der Drucker tatsächlich vorhanden ist oder nicht. Erstelle einen Ordner mit dem Namen: Drucker Erweitert.{2227A280-3AEA-1069-A2DE-08002B30309D} Das ergibt Dir einen Link zur eigentlichen Druckerauflistung wie sie früher üblich war, MS aber ausgeblendet hat. Diese wird von den Programmen verwendet. Wenn er da nicht erscheint, ist er auch nicht vorhanden. 1 Zitieren
mcdaniels 33 Geschrieben Dienstag um 19:08 Autor Melden Geschrieben Dienstag um 19:08 (bearbeitet) @WeingeistDanke werde ich mal ausprobieren. Müssten die Drucker aber dann nicht zumindest via Word ansteuerbar sein? (Selbst wenn man sie in der tollen "Druckerverwaltung" nicht sieht). bearbeitet Dienstag um 19:32 von mcdaniels Zitieren
Weingeist 165 Geschrieben Mittwoch um 07:15 Melden Geschrieben Mittwoch um 07:15 vor 11 Stunden schrieb mcdaniels: @WeingeistDanke werde ich mal ausprobieren. Müssten die Drucker aber dann nicht zumindest via Word ansteuerbar sein? (Selbst wenn man sie in der tollen "Druckerverwaltung" nicht sieht). Theoretisch schon. Doch. Nicht jedoch wenn die Probleme von den Härtungen kommen. Dann ist auch diese Auflistung manchmal etwas Random oder zäh bzw. hast Du Gewissheit, dass der Drucker unter Windows eben nicht verbunden ist und somit auch nicht verfügbar für die Programme. Daher ist das heute immer mein erster Ansatz, Treiber deinstallieren, Registry nach Printern durchsuchen, alle Anschlüsse und Warteschlangen löschen, Reboot, neueste Treiber auf Printserver installieren, einmal als Admin verbinden (ein neuerer Treiber hat den Vorteil, dass Du den alten nicht zwingend deinstallieren musst). Usern ein FQDN-Link auf den Desktop. Normal sind die Probleme dann weg. GPO so setzen das nur Admins Treiber installieren können. So als Erstmassnahme kannst auch eunfach das NTLM-Log aktivieren, falls nicht eh schon gemacht. Das Log wird regelrecht überschwemmt wenn Printer oder Netzlaufwerke sich mit Name zu verbinden versuchen. Fast vergessen, letzteres kann auch Probleme bei den Printern geben, da es der gleiche Stack ist! Also auch diese rauskicken in der Registry. Frühe war man sich fast sicher: Probleme mit Drucker = Treiber schrott. Gilt selbst heute leider noch oft. Daher nur Drucker aus dem Business-bereich, da hast eigentlich Ruhe. Die Härtungen sind aber trotzdem sehr wahrscheinlich bei Random-Problemen wie falsche Auflistung und z.B. zäher Druckeinstellungsaufruf. Du kriegst mit ein paar wenigen falsch verbundenen Druckern einen Terminal-Server in die Knie. Dies obwohl technisch gesehen, ein verbinden via Name gar nicht erst möglich sein sollte wenn NTLM blockiert wird. 1 Zitieren
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.