Netzwerkdrucker und Laufwerke auf Terminalservern - mal nicht vorhanden, mal nicht verbunden

[jBourne242 10]

Hallo Forum,

 

wir haben in einer Terminalserver-Farm einige Systeme auf Windows Server 2019 aktualisiert und seitdem dort Probleme mit den Netzwerkdruckern.

 

Sämtliche Verhalten treten bei verschiedenen Benutzern auf, jedoch auch nicht bei jeder Anmeldung, nicht immer auf dem gleichen Server.

Wir haben die Bereitstellung der Drucker bereits über eine Gruppenrichtlinie und über Skripte getestet, was auch nicht zum Erfolg geführt hat.

Ansonsten verbinden wir die Drucker eigentlich benutzerspezifisch über den Aufruf der Freigabe -> Drucker verbinden.

 

Bei manchen Benutzern fehlen Netzwerkdrucker nach der Anmeldung, diese lassen sich dann nachträglich einfach verbinden. Ist aber nervig.

Bei manchen Benutzern ist manchmal der Drucker / Standarddrucker mit einem X versehen und es besteht keine Verbindung dazu. Da hilft auch kein Doppelklick auf den Drucker, um die Verbindung aufzubauen. Wenn man den Drucker versucht zu entfernen, wird der Vorgang zwar durchgeführt, der Drucker ist aber weiterhin vorhanden. Auch mittels cmd-Befehl hat es meistens keinen Erfolg.

 

 

Bei Netzlaufwerken haben wir oftmals das Verhalten, dass die einzelnen Laufwerke zwar da sind, aber auch mit einem roten X versehen. Die Verbindung wird dann aber sofort aufgebaut, sobald man im Datei-Explorer einen Doppelklick auf das Laufwerk macht. Vorher kann man aber Verknüpfungen zu Dateien auf dem Laufwerk nicht öffnen.

 

Wir haben bereits in der Gruppenrichtlinie für die Terminalserver die Einstellung "Auf Netzwerk warten" angewendet. Auch haben wir über Skripte bei der Anmeldung versucht eine Zeitverzögerung einzusetzen. Alle Netzlaufwerke bei der Anmeldung durchzugehen und nochmals neu zu verbinden. Alles klappt dann ein paar Mal, letztlich ist der Fehler dann aber doch wieder da.

 

Aufgrund der Vielzahl von verfügbaren Druckern in der Struktur können wir die Drucker auch nicht lokal auf den Terminalservern installieren.

 

Hat jemand dazu eine Idee?

[Nobbyaushb 1.359]

Printernightmare

wir haben dann alle benötigten Drucker auf allen drei RDS Host lokal installiert 

Su muss der Anwender „nur“ seinen Standard-Drucker setzen 

Hat bei knapp 30 Anwendern prima geklappt, eine Mail an alle TS Anwender hat gereicht 

(ok, der eine oder andere hat es nicht verstanden, aber nach Schatten-Verbindung war das schnell gemacht)

Wir habe auch vorher Monate damit verbracht das über den sowieso vorhandenen Printserver umzusetzen 

So meine Erfahrung 

[Sunny61 773]

vor 5 Stunden schrieb jBourne242:

wir haben in einer Terminalserver-Farm einige Systeme auf Windows Server 2019 aktualisiert und seitdem dort Probleme mit den Netzwerkdruckern.

Wie aktualisiert? Inplace Upgrade oder Neuinstallation? Auf welchem OS läuft der Rest?

[jBourne242 10]

Das war ein Inplace-Upgrade von Windows Server 2012 R2. Es gibt derzeit noch 2 Server, die aufgrund dieser Drucker-Thematik noch nicht aktualisiert wurden. Bei denen gab es in der Vergangenheit keine Probleme.

[Nobbyaushb 1.359]

Server mit verschiedenem OS können nicht Member der gleichen Farm sein

Inplace kann klappen, muss aber nicht - wie man sieht

Bei RDS Host bevorzuge ich Neuinstallation

Aber das ist ein anderes Thema…

Über was für eine Umgebung reden wir hier?

[testperson 1.534]

Hi,

 

ich habe hier bei In-Place Updates von RDSHs auch schon Druckerprobleme im Nachgang gesehen. Das war dann i.d.R. vorbei, nachdem ein passender neuer Treiber gefunden wurde. Ich würde hier immer möglichst wenige verschiedene Treiber haben wollen und mich überwiegend an die "Typ 3" Universaltreiber der Hersteller halten.

 

Ansonsten findest du hier jede Menge, was auch noch bei Server 2016 und 2019 auftreten kann: 2012 R2 RDS - extreme Druckerprobleme - Windows Server Forum - MCSEboard.de

 

 

Gruß

Jan

[Sunny61 773]

Spricht etwas dagegen einen neuen 2019er zu installieren und mit 2 oder 3 Usern hier die Druckerthematik zu prüfen?

[Weingeist 157]

Im Grunde gibt es ein paar Grundsätze und dann sollte es (wieder) funktionieren. Habe jetzt mehrere Umgebungen aktualisiert und eigentlich spielt es gar nicht so eine Rolle ob es RDS oder andere Maschinen sind. Bei RDS ist nur das Verhalten auffälliger weil ebene deutlich mehr Köche den Brei verderben können und oft auch tun. Das Problem ist übrigens kein reines 2019 oder 2022 Problem, auch 2012R2 oder neuere Windows Clients zeigten dieses Verhalten. Manchmal ist es schlicht Zufall das es tut bzw. sieht man die Logik dahinter nicht  oder nicht auf Anhieb warum es tut oder eben nicht.

 

Das wichtigste überhaupt: Verbinden ausschliesslichen über FQDN und nicht über den Computernamen oder gar die IP. Server.domain.suffix\Freigabe

Hat man das einmal gemacht, ist das Kind im Grunde in den Brunnen gefallen.

 

Warum ist das ein Problem?

Verbindung via der IP-Adresse oder dem Computernamen werden mittels NTLM authentifziert und nicht via Kerberos. Das macht aber nicht nur bei deaktiviertem NTLM Ärger sondern eben auch wenn es noch aktiv ist. bei Netzwerkdruckern/Laufwerken kann das auch sonst reinpfuschen. Es gibt aber auch die andere Variante, trotz deaktiviertem NTLM findet eine Fallback statt und eine Verbindung kann aufgebaut werden. Aber nicht immer zuverlässig und meist grottenlahm. Wieso das geht, verschliesst sich mir.

 

• Wie verhindert man das effektiv? Keine Ahnung
• Was wenn der Ärger schon passiert ist oder die User eben selber verbinden? Mühsam
• Wie löst man es? Siehe unten =)

 

Prävention:

• Verknüpfungen auf Printserver / Fileserver in die öffentlichen Dokumente ablegen. Logischerweise als FQDN
  Sprich ich spekuliere darauf, dass die Leute zu faul sind, selber etwas einzutippen. Das funktioniert hervorragend. Zusätzlich verbinde ich die normalerweise benötigten Drucker per Login-Script. Ob man das pflegen möchte ist jedem selbst überlassen. Meine Umgebungen sind klein, Arbeitsplätze meist fix und die GL jeweils faul, daher automatisiere ich das. Je grösser und je weniger fixe Arbeitsplätze desto aufwendiger. Aber auch mehr Manpower vorhanden.
• Netzwlaufwerke versuche ich zu vermeiden, ist in der Industrie aber nicht immer möglich weil Software nicht mit UNC klarkommt.
• Dann sollte man das Rendering dem Printserver überlassen. Ich deaktiviere Client Side Rendering für Netzwerkdrucker.
• Den Tipp mit den generischen Treiber kann ich bestätigen. Und mit richtigen Business-Druckern hat man generell viel weniger Ärger mit Printern.

 

Angenommen man hat nun also den Ärger:

Abhilfe bringt hier alle Druckerverbindungen in der Registry zu löschen. Systemweit wie User-basierte. Wo die Orte sind, findet man per Registry Suche nach einem alten Drucker bzw. dem Printservernamen raus. Manchmal auch via der IP(s).

 

Auch die Anschlüsse der Drucker sollten/müssen auf die FQDN lauten. Diese werden ja oft nur einmalig erstellt, da hilft es dann nicht zwingend wenn man per FQDN verbinden möchte, der Anschluss aber als IP oder Computername hinterlegt ist. Hier liegt manchmal auch der Hund begraben wenn das vermischt wird. Wie auch immer das möglich ist, jede Kreativität konnte ich nicht nachstellen, aber so manches angetroffen und manches wohl auch durch mich verschuldet, insbesondere in älteren Umgebungen wo das FQDN-Thema noch nicht ganz so verbreitet war. Daher nach den IP-Adressen suchen und allfälige Anschlüsse rauswerfen wenn sie nicht schon andersweitig gelöscht wurden.

 

- die Auflistungen unter HKLM\System\CurrentControlSet\Control\DeviceClasses die Einträge enthalten *##?#SWD#PRINTENUM#*

- die Auflistungen unter User: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\UserSID\Printers\Connections\Printername

- die Auflistung unter: HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\UserSID\Printers\Connections\

- \HKEY_USERS\.DEFAULT\Printers\ConvertUserDevModesCount

- \HKEY_USERS\UserSID\Printers\ConvertUserDevModesCount

 

Und dann gibts noch Herstellerabhängige Einträge. Die müssen manchmal auch möglichst alle raus. Vorgängig Treiber rauswerfen verhindert potentiellen Ärger bzw. stellt sicher, dass die Einträge wieder neu angelegt werden.

 

Was mir mal aufgefallen ist, als alles nichts half (ältere Umgebung): Der Treiber muss wohl via einem Admin-Konto erstmalig auf die Maschine gelangt sein. Ist dem nicht so runterwerfen, Registry cleanen und den Drucker erstmalig mit einem Local-Admin verbinden.

 

Auf alle Fälle habe ich es bis jetzt noch nicht erlebt, das man den Printserver oder das Printing mit V3-Treiber nicht wieder sauber zum laufen bekommen hat.

 

Da meine Umgebungen immer recht überschaubar sind und das ganze sobald man weiss was man beachten muss, normal recht schnell durch ist, habe ich dazu noch kein Clean-Script geschrieben. Ist auch nicht immer ganz trivial wegen der vielen Orte wo das hin kann und GUID's die man allenfalls nicht kennt usw. Vielleicht hat ja mal jemand die Zeit und Musse dazu.