Seltsames Druckproblem: Freigegebene Windows-Drucker sind über den Hostnamen, aber nicht über die IP-Adresse erreichbar/sichtbar

Question

Seit etwa 8–10 Monaten kämpfen wir mit seltsamen Druckerproblemen, die diesen Monat in einer riesigen Anzahl von Fehlern gipfelten, in die ein Großteil des Unternehmens verwickelt war. So konnten wir die Kernprobleme identifizieren: Auf einigen Rechnern (~7–8 %) passiert manchmal nach einem Neustart etwas mit dem Druckerspooler, was dazu führt, dass Drucker nicht über die IP-Adresse, sondern nur über den Hostnamen angekündigt/verfügbar sind.

Das Problem tritt im Einzelnen auf drei Arten auf:

• Beim Senden eines Ausdrucks von einem Linux-Server wird dem Server eine Fehlermeldung angezeigt und im Ereignisprotokoll wird der folgende Fehler angezeigt: „Automatisch. Der Dienst Line Printer Daemon (LPD) hat einen Druckauftrag von %LINUXSERVERIP% für den Drucker \%WindowsIP%%PrinterName% abgelehnt, da der angegebene Drucker auf diesem Computer nicht vorhanden ist.“

• Beim Versuch, einen Drucker über den Windows Explorer zuzuordnen, indem Sie mit \%WindowsIP%\ im Windows Explorer zum Windows-Computer gehen, wird der Drucker angezeigt, aber der Versuch, ihn hinzuzufügen, führt zu dem Fehler „Der Vorgang konnte nicht abgeschlossen werden (Fehler 0x00000709)“. Dies wird im Allgemeinen mit KBKB5006670 in Verbindung gebracht, ist aber nicht auf unseren Computern installiert und die ersten Fälle des oben genannten Fehlers stammen aus dem Dezember 2021/Januar 2022, also lange bevor dieser Patch überhaupt veröffentlicht wurde.

• Beim Ausführen des Powershell-Befehls Get-Printer -Computername %WindowsIP%. Wenn der Befehl mit dem Hostnamen des Computers ausgeführt wird, ist das Ergebnis korrekt (eine Liste freigegebener Drucker). Wenn er mit der IP-Adresse des Computers ausgeführt wird, wird der folgende Fehler ausgegeben:

    + CategoryInfo          : NotSpecified: (MSFT_Printer:ROOT/StandardCimv2/MSFT_Printer) [Get-Printer], CimException
    + FullyQualifiedErrorId : HRESULT 0x8007007b,Get-Printer
  

Und das nervigste ist: Wenn Sie den Spooler-Dienst neu starten, verschwindet das Problem vollständig bis zum nächsten Neustart ...

Die Recherche bei Google war nicht sehr erfolgreich, abgesehen von einer einzigen unbeantworteten Nachricht:https://hardforum.com/threads/weird-network-printing-problem.1635293/

Es gibt für alles eine XKCD, oder nicht?https://xkcd.com/979/

Zusätzliche Analysen wurden mit Procmon, Wireshark, Process Explorer, WinDbg und xbootmgr mit folgenden Ergebnissen durchgeführt:

• Procmon:

  • Die Analyse von spoolsv.exe während der Ausführung von Get-Printer %WindowsIP% von einem anderen Computer zeigt keine anderen Aktionen als die Netzwerkkommunikation
  • Die Analyse von spoolsv.exe während des Hinzufügens eines freigegebenen Druckers über den Windows Explorer zeigt die Netzwerkverbindung und einige RegQueryKey für HKU%SIDOFREMOTEACCOUNT% und HKU.DEFAULT\Printers\Connections,,%WINDOWSIP%,%PRINTERNAME% mit dem Ergebnis „NAME NOT FOUND“, aber sonst nichts.
  • Der Versuch, spoolsv.exe während des Bootvorgangs über die Option „Boot-Protokollierung aktivieren“ zu analysieren, war erfolgreich, aber nutzlos, da das Problem beim Booten mit aktivierter Option nicht auftrat.
  • Es wurde versucht, mithilfe der Stack Summary Function eine zusätzliche Analyse durchzuführen, um den Stack von spoolsv.exe aus zurückzuverfolgen. Der einzige erkennbare gemeinsame Unterschied im Thread zwischen dem funktionierenden und dem nicht funktionierenden Procmon-Dump war jedoch das Vorhandensein eines zusätzlichen Zweigs namens EatAuthInfoFromPacket im Dump des funktionierenden Dienstes.

• Wireshark:

  • Eine oberflächliche Analyse des Datenverkehrsflusses bei der Ausführung von Get-Printer von einem Remote-Computer zeigt eine winspool_AsyncEnumPrinters-Anforderung und eine winspool_AsyncEnumPrinters-Antwort mit dem Protokoll IREMOTEWINSPOOL, aber keine zusätzlichen Informationen. Die Stub-Daten scheinen verschlüsselt zu sein, sodass ich keine zusätzlichen Informationen daraus gewinnen kann.

• Process Explorer

  • Es wurde eine oberflächliche Analyse des Prozesses spoolsv.exe und seiner Threads und Stacks durchgeführt und der einzige interessante Punkt war, dass in den Strings des Prozesses spoolsv.exe \machinehostname und \machinehostname.domain.com standen, als er defekt war, und nichts, als er nicht defekt war. Aber ich muss zugeben, dass meine Kenntnisse der Windows-Interna nicht ausreichen, um alles zu verstehen. OpenAI hat jedoch bei den Erklärungen geholfen!

• WinDbg

  • Der Debugger wurde an den Prozess spoolsv.exe angehängt und Tests wurden sowohl mit Get-Printer von einem Remote-Rechner als auch mit dem Versuch, den Drucker über den Windows Explorer zuzuordnen, durchgeführt, aber in beiden Fällen waren während der Ausführung keine Debug-Meldungen sichtbar. Zusätzlich habe ich einen Prozessdump vom Process Explorer erstellt und ihn an WindDbg weitergeleitet, um den Befehl !analyze auszuführen, aber er hat nur einen Haltepunkt zurückgegeben, keinen tatsächlichen Fehler. Wie zuvor bin ich neu bei diesem Tool, also nehme ich gerne Vorschläge entgegen, wenn Sie welche haben!

• xbootmgr

  • xbootmgr -trace boot -traceflags dispatcher+latency -stackwalk readythread+threadcreate+profile+cswitch wurde ausgeführt, um den Dienst während des Bootens zu debuggen, aber wie bei Procmon tritt das Problem beim Neustart der Maschine mit dieser Ablaufverfolgung nicht auf, sodass die Ausgabe ziemlich nutzlos ist

Und das ist also die Zusammenfassung. Ich bin ein wenig ratlos und weder Google noch OpenAI scheinen eine Ahnung zu haben, was hier vor sich geht. Daher würde ich mich über alle Erkenntnisse freuen, die Sie mir zur weiteren Fehlerbehebung für dieses Problem oder vielleicht zu einer Lösung geben können, wenn Sie schon einmal damit konfrontiert waren.

Answer 1

Falls jemand anderes das Problem hat, hier die Antwort von Microsoft:

Die Ursache (Hintergrundgeschichte) ist mehrschichtig. Dies ist die grundlegende Zusammenfassung. Dienststart Es gab viele Änderungen in Windows, um die Startzeiten von Diensten beim Booten zu verbessern. Dadurch können einige Dienste früher als in der Vergangenheit gestartet werden. Ein Dienst kann möglicherweise nicht gestartet werden, wenn er eine Netzwerkabhängigkeit hat und eine Zeitüberschreitung auftritt, bevor DAD abgeschlossen ist und die Schnittstelle und IP einsatzbereit sind. Hardware Verbesserungen bei der Computerhardware sind ein wichtiger Faktor. Alle modernen Prozessoren haben mehrere Kerne/Threads, wodurch die parallele Verarbeitung von Betriebssystemaufgaben möglich ist. Auch die Geschwindigkeit der Prozessoren hat sich dramatisch erhöht. Diese Änderungen ermöglichen es einem Betriebssystem wie Windows, mehrere Aufgaben schneller und parallel auszuführen und so die Startzeit von Diensten dramatisch zu verbessern. Die Menge des verfügbaren RAM hat schnell zugenommen. Dies bedeutet weniger Paging auf die Festplatte, was ebenfalls die Startzeit verbessert. Die bedeutendste Verbesserung wurde beim Speicher vorgenommen. Der Speicher ist jetzt hauptsächlich Flash-basiert (SSD) und verwendet üblicherweise eine Hochgeschwindigkeits-NVMe-Verbindung. Sogar Speicher-Backends wie ein NAS oder SAN sind heutzutage vollständig Flash-basiert. Die Verbesserungen bei IO, Latenz und Durchsatz zwischen alten Festplatten (HDD) und NVMe-SSDs liegen in einer Größenordnung von über 150 Mal schneller. Diese Änderung erfolgte in einer Zeitspanne von weniger als 10 Jahren. Das Ergebnis: Vor den Verbesserungen dauerte es zweistellige Sekunden, bis Dienste beim Booten gestartet wurden. Als DAD erstmals zu Windows hinzugefügt wurde, konnte es Minuten dauern, bis alle Dienste bereit waren. Eine Kompensation für DAD war nicht erforderlich, daher ignorierte der meiste Code einfach den IP-Adressstatus. Die kombinierte Änderung des Dienststartverhaltens und die jüngsten Hardwareverbesserungen haben es ermöglicht, dass der Dienststart im einstelligen Sekundenbereich dauert. Lange bevor eine IP-Adresse einsatzbereit ist, basierend auf dem Windows-Verhalten und den RFC-Anforderungen. Das einfache Ändern des DAD-Übertragungsstandards für IPv4 auf 1 ist keine langfristige Lösung. Da sich Hardware und Dienste weiter verbessern, ist es möglich, dass sogar eine Verzögerung von einer einzigen Sekunde ausreicht, um einen Dienstfehler beim Booten zu verursachen. Dienste, bei denen das Problem auftritt, müssen so geändert werden, dass sie den IP-Adressstatus überwachen, bevor sie eine Netzwerkverbindung herstellen oder eine Bindung an eine IP herstellen. Bekannte Probleme Dies ist eine Liste allgemeiner Probleme, die bei CSS im Zusammenhang mit DAD und dem Starten von Diensten auftreten können. Dienst, der ein Domänenkonto verwendet, startet nicht Dienste, die ein Domänenkonto verwenden, sind in besonderer Weise davon abhängig, dass das Netzwerk bereit und zugänglich ist, um die Authentifizierung beim Domänencontroller durchzuführen. Der Dienst startet nicht ohne Authentifizierung. Wenn der Dienst schneller startet und das Zeitlimit überschritten wird, als es dauert, bis das Netzwerk bereit ist, was normalerweise damit zusammenhängt, dass auf die Fertigstellung von DAD gewartet wird, startet der Dienst nicht. Dies tritt häufig bei SQL Server auf, kann aber bei jedem Dienst passieren, der ein Domänenkonto zur Anmeldung verwendet.

Dieses Problem kann umgangen werden, indem die Anzahl der DAD-Übertragungen verringert, DAD deaktiviert oder die Wiederherstellungsoption des Dienstes auf Neustart eingestellt wird. Siehe die Problemumgehung:

Dienst kann beim Start nicht an eine IP-Adresse gebunden werden. Dieses Problem tritt auf, wenn der Dienst versucht, einen Dienst an eine IP-Adresse zu binden, aber eine Zeitüberschreitung oder ein Fehler auftritt, bevor das Netzwerk bereit ist. Auch dies geschieht normalerweise aufgrund der DAD-Wartezeit. Der Netzwerkstapel kann einen Dienst nicht an eine IP-Adresse binden, die sich nicht im bevorzugten Status befindet. Dieses Problem tritt häufig beim Spooler-Dienst (Druckserver) auf. Probleme wie dieses können umgangen werden, indem DAD deaktiviert oder der Dienststart auf „Automatisch (verzögerter Start)“ eingestellt wird. Andere Problemumgehungen funktionieren möglicherweise nicht, wenn der Dienst nicht ausfällt/stoppt, sondern einfach weiterläuft, ohne dass ein Dienst an eine IP-Adresse gebunden wird. IPv6-Adressen verschwinden beim Neustart vom DNS-Server. Der DHCP-Client kann eine DNS-Registrierung anfordern, bevor IPv6 DAD abgeschlossen ist. Wenn dies geschieht, wird die IPv6-Adresse während der dynamischen DNS-Aktualisierung durch den DNS-Client vom DNS-Server gelöscht/verschwindet.

Ich hoffe, dass dies Ihnen weiterhilft und möchte Sie darauf aufmerksam machen, dass derzeit noch keine endgültige Lösung gefunden wurde.