9
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
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 480357
Url: https://administrator.de/contentid/480357
Printed on: April 18, 2024 at 20:04 o'clock
9 Comments
Latest comment
Hi,
ein altes Problem, für welches es meines Wissens keine "saubere" Lösung gibt.
2 Ansätze:
E.
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.
E.
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:
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!
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
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?Ich habe jetzt mal einen "Sleep" ins Logon-Skript gemacht und lasse darauf warten.
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.
Da reicht ein anderes Modell oder ein andere Treiberversion, um den Unterschied auszumachen.
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:
Na ja. Hat eigentlich nichts mit Windows zu tun. Sondern nur dem Drucker- und/oder Treiberhersteller.
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.
Hallo!
Es wäre ja auch ausreichend, es gäbe eine Funktion: Warte auf die Drucker...
Asynchrone Verarbeitung ist natürlich aktiviert.
Es wäre ja auch ausreichend, es gäbe eine Funktion: Warte auf die Drucker...
Asynchrone Verarbeitung ist natürlich aktiviert.
Na dann kannst Du das mit dem Warten im Script auch vergessen.
