2
Standarddrucker ändert sich während einer Remotedesktop Session
Hallo,
ich habe hier eine interessante Herausforderung:
Infrastruktur:
- 2 Domaincontroller (Windows 2012r2 Standard)
- 2 Terminalserver (Windows 2012r2 Standard)
- 1 Fileserver (Windows 2012r2 Standard)
- ca. 100 User an 14 Standorten
- ca. 60 Drucker im Netzwerk
- die User arbeiten an IGEL und Terra ThinClients (also vollständig mit RemoteDesktop)
- Option "Standarddruckgerät des Clients verwenden" ist deaktiviert (sowohl im AD als auch im RDSH)
- Druckerhersteller: HP, Kyocera, und Brother
- Remotedesktop Session Host läuft auf DC 1
- Printserver läuft auf DC 2
- UVHDs der UserProfileDisks liegen auf dem FS
- Drucker werden über GPOs basierend auf Standort-IPs verteilt
- Es werden keine Standarddrucker per GPO zugewiesen
Problem:
Bei einigen Benutzern ändert sich laufend der Standarddrucker.
Nicht nur nach dem Ab-/Anmelden sondern auch während der laufenden Session.
In einem Moment ist Drucker A der Standard und im nächsten Moment ist es Drucker B oder auch C (gleiches Programm - anderes Dokument).
Das einzige, was ich dazu im Log gefunden habe unter
Anwendungs- und Dienstprotokolle -> Microsoft -> Windows -> PrintService
ist folgender Eintrag:
UserData
- ChangingDefaultPrinter
DefaultPrinterSelectedBySpooler 1
OldDefaultPrinter -
NewDefaultPrinter \\DC 2\Drucker B,winspool,Ne03:
Status 0x0
Module spoolsv.exe
Natürlich ist das für den User extrem lästig (würde mich auch nerven, wenn ich so viel drucken müsste der der User)
Bei der Suche im Internet bin ich auf keine passende Lösung oder ein ähnliches Problem gestoßen.
Nachvollziehen / Nachstellen kann ich das Problem mit dem Test-User ebenfalls nicht.
Kann mir hier jemand helfen, dieses Problem abzustellen?
Vielen Dank
ich habe hier eine interessante Herausforderung:
Infrastruktur:
- 2 Domaincontroller (Windows 2012r2 Standard)
- 2 Terminalserver (Windows 2012r2 Standard)
- 1 Fileserver (Windows 2012r2 Standard)
- ca. 100 User an 14 Standorten
- ca. 60 Drucker im Netzwerk
- die User arbeiten an IGEL und Terra ThinClients (also vollständig mit RemoteDesktop)
- Option "Standarddruckgerät des Clients verwenden" ist deaktiviert (sowohl im AD als auch im RDSH)
- Druckerhersteller: HP, Kyocera, und Brother
- Remotedesktop Session Host läuft auf DC 1
- Printserver läuft auf DC 2
- UVHDs der UserProfileDisks liegen auf dem FS
- Drucker werden über GPOs basierend auf Standort-IPs verteilt
- Es werden keine Standarddrucker per GPO zugewiesen
Problem:
Bei einigen Benutzern ändert sich laufend der Standarddrucker.
Nicht nur nach dem Ab-/Anmelden sondern auch während der laufenden Session.
In einem Moment ist Drucker A der Standard und im nächsten Moment ist es Drucker B oder auch C (gleiches Programm - anderes Dokument).
Das einzige, was ich dazu im Log gefunden habe unter
Anwendungs- und Dienstprotokolle -> Microsoft -> Windows -> PrintService
ist folgender Eintrag:
UserData
- ChangingDefaultPrinter
DefaultPrinterSelectedBySpooler 1
OldDefaultPrinter -
NewDefaultPrinter \\DC 2\Drucker B,winspool,Ne03:
Status 0x0
Module spoolsv.exe
Natürlich ist das für den User extrem lästig (würde mich auch nerven, wenn ich so viel drucken müsste der der User)
Bei der Suche im Internet bin ich auf keine passende Lösung oder ein ähnliches Problem gestoßen.
Nachvollziehen / Nachstellen kann ich das Problem mit dem Test-User ebenfalls nicht.
Kann mir hier jemand helfen, dieses Problem abzustellen?
Vielen Dank
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 331045
Url: https://administrator.de/forum/standarddrucker-aendert-sich-waehrend-einer-remotedesktop-session-331045.html
Ausgedruckt am: 10.04.2025 um 21:04 Uhr
2 Kommentare
Neuester Kommentar
Moin,
Das Problem gibt es schon ewig. Viele Lösungsansätze. Es soll wohl mit einigen Zusatzprodukten wie Slimprinter lösbar sein:
Umgeleitet Drucker in TS-Sitzung
Wir haben eine ähnliche Umgebung wie ihr allerdings auf W2008R2.
Wir haben den Verdacht, dass das Problem bei der Anmeldung dann auftaucht wenn der Drucker zugewiesen wird aber nocht nicht erreichbar ist (warum auch immer).
Mein Workaround ist unflexibel und aufwendig, in anderen Umgebungen nur bedingt eine Lösungsmöglichkeit, aber funktioniert weitgehend:
Im Anmeldescript ist eine Zeitverzögerung und dann wird der Drucker fest zugeordnet
timeout /t 20
rundll32 printui.dll,PrintUIEntry /y /n "Druckername"
Henning
Bei der Suche im Internet bin ich auf keine passende Lösung
Das glaube ich dir...oder ein ähnliches Problem gestoßen.
...das eher nichtDas Problem gibt es schon ewig. Viele Lösungsansätze. Es soll wohl mit einigen Zusatzprodukten wie Slimprinter lösbar sein:
Umgeleitet Drucker in TS-Sitzung
Wir haben eine ähnliche Umgebung wie ihr allerdings auf W2008R2.
Wir haben den Verdacht, dass das Problem bei der Anmeldung dann auftaucht wenn der Drucker zugewiesen wird aber nocht nicht erreichbar ist (warum auch immer).
Mein Workaround ist unflexibel und aufwendig, in anderen Umgebungen nur bedingt eine Lösungsmöglichkeit, aber funktioniert weitgehend:
Im Anmeldescript ist eine Zeitverzögerung und dann wird der Drucker fest zugeordnet
timeout /t 20
rundll32 printui.dll,PrintUIEntry /y /n "Druckername"
Nicht nur nach dem Ab-/Anmelden sondern auch während der laufenden Session.
Das könnte damit zusammenhängen, dass der Printserver aus irgendeinem Grund zwischendurch nicht erreichbar ist?Henning
Hallo,
danke für die schnelle Erstreaktion.
Zusatzprodukte sind leider keine Option. Das will der Kunde nicht.
Daran liegts nicht - der hängt in der gleichen Umgebung wie der TS und ist zudem der 2. DC. Müsste dann außerdem auch dann wieder alle User betreffen.
danke für die schnelle Erstreaktion.
Zitat von @vossi31:
Das Problem gibt es schon ewig. Viele Lösungsansätze. Es soll wohl mit einigen Zusatzprodukten wie Slimprinter lösbar sein:
Umgeleitet Drucker in TS-Sitzung
Das Problem gibt es schon ewig. Viele Lösungsansätze. Es soll wohl mit einigen Zusatzprodukten wie Slimprinter lösbar sein:
Umgeleitet Drucker in TS-Sitzung
Zusatzprodukte sind leider keine Option. Das will der Kunde nicht.
Wir haben den Verdacht, dass das Problem bei der Anmeldung dann auftaucht wenn der Drucker zugewiesen wird aber nocht nicht erreichbar ist (warum auch immer).
Dann müsste es alle User betreffenIm Anmeldescript ist eine Zeitverzögerung und dann wird der Drucker fest zugeordnet
timeout /t 20
rundll32 printui.dll,PrintUIEntry /y /n "Druckername"
Es wird kein Anmeldescript benutzt sondern nur über GPO gearbeitet - Kunde will das sotimeout /t 20
rundll32 printui.dll,PrintUIEntry /y /n "Druckername"
Nicht nur nach dem Ab-/Anmelden sondern auch während der laufenden Session.
Das könnte damit zusammenhängen, dass der Printserver aus irgendeinem Grund zwischendurch nicht erreichbar ist?
