Windows 2012 R2 - Drucker erst einige Sekunden nach Anmeldung verfügbar

Hallo!

Ich habe ein Problem mit einem Windows 2012 R2 Terminalserver.
Die User melden sich an und haben alle Drucker, die über das Netzwerk angelegt sind. Die Drucker sind wiederum auf einem Windows 2012 R2 Server angelegt.

Das Problem ist jetzt:
Die Drucker benötigen einige Sekunden, um voll verfügbar zu sein. Vorher haben sie noch den "schwarzen Kringel" in der Geräteverwaltung. Die User nutzen eine Anwendung bei der nur Drucker funktionieren, die beim Start der Anwendung verfügbar waren. Starten die User die Anwendung DIREKT, fehlen Drucker.

Noch einige Details:
- Die Druckertreiber sind auf dem Terminalserver alle verfügbar und müssen gar nicht geladen werden.
- Die User nutzen Roaming-Profile
- Die Drucker wurden "von Hand" gemappt und werden nicht erst beim Login eingebunden

Habt ihr eine Idee, wie ich das Verhalten ändern kann?

Danke und Grüße
Phil

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 480357

Url: https://administrator.de/forum/windows-2012-r2-drucker-erst-einige-sekunden-nach-anmeldung-verfuegbar-480357.html

Ausgedruckt am: 02.04.2025 um 12:04 Uhr

9 Kommentare

Neuester Kommentar

Hi,
ein altes Problem, für welches es meines Wissens keine "saubere" Lösung gibt.

Die Drucker wurden "von Hand" gemappt und werden nicht erst beim Login eingebunden

Das ist irrelevant, weil sie dann so oder so im Roaming Profile stehen und bei Anmeldung deswegen wiederverbunden werden.

Habt ihr eine Idee, wie ich das Verhalten ändern kann?

Selbst die Verwendung von GPP ändert daran nichts.

2 Ansätze:

Drucker doch per Loginscript verbinden und die asynchrone Verarbeitung der Loginscripte per GPO deaktivieren. Dadurch wartet der Explorer mit dem Start (Anzeige des Desktop), bis alle Scripte fertig sind. Demnach müssten dann also die Drucker verfügbar sein. Allerdings funktioniert das nicht mit veröffentlichten Anwendungen, nur bei vollem Desktop.
Anwendung nicht direkt starten sondern stattdessen ein Script. Das Script prüft ob - und wartet ggf. bis - alle relevanten Drucker verbunden sind und startet dann erst die betreffende Anwendung.

Moin,

ich hatte ein ähnlich gelagertes Problem. Der TS hat sich immer den PDF-Creator als Standarddrucker gegriffen, weil die auf dem Client vorhandenen Drucker noch nicht vorhanden waren. Das habe ich mit einem kleinen PS-Skript gelöst:

Start-Sleep 20
$printer = $(Get-WmiObject -class win32_printer | Where-Object { $_.name -like "*wasauchimmer*" })  
$printer.setdefaultprinter()
Add-Type -Assembly 'System.Windows.Forms'  

[Windows.Forms.MessageBox]::Show("Druckereinrichtung abgeschlossen ...”, "", [Windows.Forms.MessageBoxButtons]::OK, [Windows.Forms.MessageBoxIcon]::Information)  

Dann habe ich den Usern gesagt, dass sie die Software erst nach der Meldung öffnen dürfen. In Deinem Fall könnten sogar die erste und die letzten beiden Zeilen des Skripts reichen. Die anderen Zeilen brauche ich nur, weil verschiedene Abteilungen verschiedene Standarddrucker brauchen.

hth

Erik

P. S.: Ich hasse Drucker!

Hallo!

Danke für eure Tipps. Das klingt leider wenig erbaulich.

Ich habe jetzt mal einen "Sleep" ins Logon-Skript gemacht und lasse darauf warten.
...hatte auf eine schönere Lösung gehofft.

Das Eigenartige ist, dass meine anderen Terminalserver dieses Verhalten nicht zeigen, aber der neueste Server hat eben auch noch performantere Hardware und "überholt" vielleicht die Drucker

P.S.: Jeder hasst Drucker - oder noch schlimmer: Faxgeräte

Zitat von @Der-Phil:
Ich habe jetzt mal einen "Sleep" ins Logon-Skript gemacht und lasse darauf warten.

Worauf?
Und, ohne die asynchrone Verarbeitung zu deaktivieren, nützt das allein doch auch nichts?

Das Eigenartige ist, dass meine anderen Terminalserver dieses Verhalten nicht zeigen, aber der neueste Server hat eben auch noch performantere Hardware und "überholt" vielleicht die Drucker

Da reicht ein anderes Modell oder ein andere Treiberversion, um den Unterschied auszumachen.

Zitat von @emeriks:
Da reicht ein anderes Modell oder ein andere Treiberversion, um den Unterschied auszumachen.

Wie immer bei Windows. Mal gates und mal gates nicht.

Zitat von @erikro:
Wie immer bei Windows. Mal gates und mal gates nicht.

Na ja. Hat eigentlich nichts mit Windows zu tun. Sondern nur dem Drucker- und/oder Treiberhersteller.

Zitat von @emeriks:

Zitat von @erikro:
Wie immer bei Windows. Mal gates und mal gates nicht.

Na ja. Hat eigentlich nichts mit Windows zu tun. Sondern nur dem Drucker- und/oder Treiberhersteller.

Naja, unter Linux habe ich das noch nie erlebt, dass auf dem Printserver angelegte Drucker auf dem Client Ärger machen. Da geht es entweder oder es geht nicht. Aber da liegt dann die Schuld fast immer am Admin, der was falsch gemacht hat. Aber dieses Rumgezicke, dass es auf dem einen Client geht und auf dem anderen nicht oder es gar auf demselben Client mal ja und mal nein, kenne ich da nicht.