none
Probleme mit Druckern auf Remote-Desktop-Host 2012R2 RRS feed

  • Allgemeine Diskussion

  • Hallo,

    wir haben bei einem Kunden massive Probleme mit dem verbinden von freigegebenen Druckern in einer Remote-Desktop Farm.

    Der Aufbau sieht folgendermaßen aus (alle Server sind 2012R2):

    • FILE1 ist File- und Printserver; hier sind die Drucker (sehr gemischt: HP, Brother, Epson, KonicaMinolta, Kyocera) installiert und freigegeben
    • DC1 + DC2 sind die Domaincontroller + DNS + DHCP
    • RD1 + RD2 sind die Remote-Desktop-Sitzungshost (konfiguriert als Farm inkl. Lastausgleich)
    • das Mapping der Drucker läuft über con2prt.exe in einem Logon-Skript (zunächst werden alle Verbindungen gelöscht, dann neu gemappt)
    • Alle User haben Serverseitige Profile; jeweils für Sitzungen am PC und am Remote-Desktop-Host
    • "durchschleifen" der Drucker ist abgeschaltet

    Das Problem stellt sich folgendermaßen dar:

    Die User beschwerten sich anfangs, dass der Standard-Drucker falsch festgelegt sei. Die Zuordnung dessen erfolgt im o.g. Anmeldeskript per con2prt.exe /cd. Bei genaueren testen stellten wir zunächst fest, dass der Aufruf con2prt.exe /f gar nicht alle verbunden Drucker löscht. Wenn man nach der Anmeldung unter Geräte und Drucker nachschaut, sind teilweise einige Drucker doppelt oder gar dreifach vorbunden. Kurios ist auch, dass ein User einige verbundenen Drucker löschen darf, andere aber nicht (Admin Authentifizierung notwendig).

    Ich habe dieses Scenario mal mit einem Test-User durchgespielt. Zunächst habe ich dem User per Skript alle Drucker gemappt (ca. 20 Drucker) -> So weit so gut. Danach den User abgemeldet, im Skript einige Drucker entfernt, und schließlich wieder angemeldet -> con2prt.exe /f hat hier nur ca. 7 von 20 Druckern gelöscht und danach die entsprechenden Drucker verbunden. Wenn man gleich nach der Anmeldung unter Drucker und Geräte schaut, fällt auf dass hier nach und nach wieder neue Drucker dazu kommen, die aber nicht im Anmeldeskript stehen. Beim manuellen Löschen braucht man bei einigen Druckern auch wieder eine Admin-Authentifizeirung.

    Wir sind mit unserem Latein am Ende. Bisher haben wir alle Druckertreiber auf die neueste Version aktualisiert und mit mehreren Useren (auch von uns neu erstellte) unzählige Scenarios getestet.

    Hat evtl. noch jemand einen Tip für uns??

    • Typ geändert Alex Pitulice Dienstag, 22. April 2014 19:52 Warten auf Feedback
    Montag, 14. April 2014 13:37

Alle Antworten

  • Hi,

    Am 14.04.2014 15:37, schrieb Mark Henkel:

    con2prt.exe /f hat hier nur ca. 7 von 20 Druckern gelöscht und danach
    die entsprechenden Drucker verbunden. Wenn man gleich nach der
    Anmeldung unter Drucker und Geräte schaut, fällt auf dass hier nach
    und nach wieder neue Drucker dazu kommen, die aber nicht im
    Anmeldeskript stehen. Beim manuellen Löschen braucht man bei einigen
    Druckern auch wieder eine Admin-Authentifizeirung.

    Ich denke ihr verteilt die Drucker mit mehr als einer Technik.
    script + CSE PRinter oder Bereitgestellte Drucker

    Über die CSEs werden die Drucker als SYSTEM an den User übergeben und der User kann sie dann im eigenen Context mit "con2prt.exe" löschen, sie gehören ihm nicht.

    Ebenfalls für eine 2te Technik spricht das verhalten, daß nachträglich Drucker erscheinen, was im Falle einer Asynchronen Anmeldung/Startverhalten der CSEs ebenfalls der Fall ist.

    Durchsuche ALLE Richtlinien nach Druckern.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Montag, 14. April 2014 15:43
  •  Am 14.04.2014 17:43, schrieb Mark Heitbrink [MVP]:

    Über die CSEs werden die Drucker als SYSTEM an den User übergeben und
    der User kann sie dann im eigenen Context mit "con2prt.exe" löschen,

    NICHT! ... kann nicht löschen :-) Sonst macht der Nachsatz keine Sinn.

    sie gehören ihm nicht.

    --
    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Montag, 14. April 2014 16:38
  • Hallo,

    ich habe jetzt alle Richtlinien nach Druckern durchsucht - hier ist nix zu finden.

    Ebenfalls sind auf den Hosts folgende Richtlinien aktiviert:

    • Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten
    • Anmeldeskripts gleichzeitig ausführen
    • Anweisungen in Startskripts während der Ausführung anzeigen

    Die ersten beiden aufgeführten Richtlinien müssten doch dafür sorgen, dass die Anmeldung "synchron" erfolgt, oder?

    Montag, 14. April 2014 17:38
  • Am 14.04.2014 schrieb Mark Henkel:

    ich habe jetzt alle Richtlinien nach Druckern durchsucht - hier ist nix zu finden.

    Leg eine neue leere OU an, Veerbung der GPOs von oben deaktivieren und
    die Drucker per Script zuweisen. Testen und prüfen was auf den Clients
    passiert.

    Ebenfalls sind auf den Hosts folgende Richtlinien aktiviert:

    * Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten
    * Anmeldeskripts gleichzeitig ausführen
    * Anweisungen in Startskripts während der Ausführung anzeigen

    Die ersten beiden aufgeführten Richtlinien müssten doch dafür sorgen, dass die Anmeldung "synchron" erfolgt, oder?

    Kommen die Einstellungen auch auf den Clients an?


    Servus
    Winfried

    Gruppenrichtlinien
    WSUS Package Publisher
    HowTos zum WSUS Package Publisher
    NNTP-Bridge für MS-Foren

    Montag, 14. April 2014 19:23
  • Leg eine neue leere OU an, Veerbung der GPOs von oben deaktivieren und

    die Drucker per Script zuweisen. Testen und prüfen was auf den Clients
    passiert.

    Das habe ich gemacht. Habe jetzt nur die Richtlinien "Drucker per Skript" und "Einstellungen Anmeldeskript" (Anmeldeskript gleichzeitig ausführen + Anmeldeskript sichtbar ausführen) verknüpft.

    Kommen die Einstellungen auch auf den Clients an?

    Ja, habe ich mittels gpresult /h bzw. rsop.msc geprüft.

    Habe nun zunächst beim Test-User alle Drucker manuell getrennt und dann den User abgemeldet. Dann im Skript alle Drucker scharf geschaltet und erneut angemeldet -> Die Drucker werden sauber verbunden.

    Dann wieder abgemeldet und die Drucker im Skript auskommentiert. Nun erneut angemeldet und festgestellt, dass con2prt.exe /f keinen einzigen Drucker gelöscht hat (habe eine Pause im Skript, damit ich alles sehe).

    Rufe ich nach der Anmeldung das Skript manuell auf, funktioniert alles.

    Dienstag, 15. April 2014 06:57
  • Hi,

    ich habe zwar keine Lösung für Dein Problem, würde mich aber dem gern anschließen, da ich bisher dachte, ich hätte irgendwas falsch konfiguriert.

    Bei uns gibt es aber das gleiche Problem. Wir verfahren so, dass wir die Druckertreiber als Administrator aktualisieren, indem wir von jedem Modell einen Drucker auf dem RD-Server installiert haben (als Netzwerkdrucker). Nun ist es aber so, dass bei den Benutzern dadurch anscheinend auch Drucker anderer Niederlassungen eingebunden werden. Werden diese gelöscht, so tauchen sie nach kurzer Zeit einfach wieder auf. Irgendwann benötigt man sogar Admin-Rechte, um den Drucker zu löschen, obwohl es ein Netzwerkdrucker ist.

    Das scheint mir ein Bug in Server 2012 R2 zu sein. Ich habe alle möglichen Sachen ausprobiert (Registry-Einträge gelöscht, GPOs erstellt, die alle Drucker löschen sollen), ohne Erfolg. Sie tauchen einfach immer und immer wieder auf. Wir haben schließlich die komplette RD-Farm neu installiert und fügen die Treiber nur noch über die Druckerservereigenschaften hinzu.

    Wenn es eine Lösung hierfür (vielleicht als Hotfix oder Update Rollup) gäbe, wäre das toll.

    Gruß

    Ben

    Dienstag, 15. April 2014 07:07
  • Hallo,

    ist ja schon mal beruhigend, dass wir mit dem Problem nicht alleine sind.

    Ich dachte anfangs auch es läge an Server 20012R2; jetzt habe ich die o.g. Tests allerdings auf einer 2008R2 Farm gemacht (der Print-Server ist noch 2012R2) und trotzdem die Probleme...

    Dienstag, 15. April 2014 07:16
  • Am 15.04.2014 schrieb Mark Henkel:

    Leg eine neue leere OU an, Veerbung der GPOs von oben deaktivieren und


    die Drucker per Script zuweisen. Testen und prüfen was auf den Clients
    passiert.

    Das habe ich gemacht. Habe jetzt nur die Richtlinien "Drucker per Skript" und "Einstellungen Anmeldeskript" (Anmeldeskript gleichzeitig ausführen + Anmeldeskript sichtbar ausführen) verknüpft.

    Kommen die Einstellungen auch auf den Clients an?

    Ja, habe ich mittels gpresult /h bzw. rsop.msc geprüft.

    OK.

    Habe nun zunächst beim Test-User alle Drucker manuell getrennt und dann den User abgemeldet. Dann im Skript alle Drucker scharf geschaltet und erneut angemeldet -> Die Drucker werden sauber verbunden.

    Dann wieder abgemeldet und die Drucker im Skript auskommentiert. Nun erneut angemeldet und festgestellt, dass con2prt.exe /f keinen einzigen Drucker gelöscht hat (habe eine Pause im Skript, damit ich alles sehe).



    Rufe ich nach der Anmeldung das Skript manuell auf, funktioniert alles.

    Und keine Fehlermeldungen im Eventlog?

    Gibt es einen guten Grund nicht auf Group Policy Preferences
    umzustellen?


    Servus
    Winfried

    Gruppenrichtlinien
    WSUS Package Publisher
    HowTos zum WSUS Package Publisher
    NNTP-Bridge für MS-Foren

    Dienstag, 15. April 2014 19:23
  • Am 15.04.2014 09:16, schrieb Mark Henkel:

    Ich dachte anfangs auch es läge an Server 20012R2; jetzt habe ich die
    o.g. Tests allerdings auf einer 2008R2 Farm gemacht (der Print-Server
    ist noch 2012R2) und trotzdem die Probleme...

    Wir reden jetzt aber nicht über Drucker, die über das RDP Protokoll, bzw. Easy Print in die Session kommen, oder?

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Mittwoch, 16. April 2014 09:50
  • Hallo,

    ich dachte schon ich bin mit diesen Problemen allein. Der Server 2012 R2 hat wohl ein massives Problem mit Netzwerkdruckern im Zusammenhang mit RDP. Egal wie man die Drucker den Benutzern zuweist (manuell mit dem Windows Explorer, per Gruppenrichtlinien oder auch mit con2prt.exe. Die Drucker tauchen nach einer Zeit gruppiert mit dem selben Namen 2 x auf, manchmal erscheint der grüne Hacken beim Standarddrucker nicht (Dann kann der Acrobat XI nicht mehr drucken, siehe http://forums.adobe.com/message/6145875 ), manchmal kann man einen verbunden Drucker nicht mehr löschen. Wenn man den Key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider" löscht und die Druckerwarteschlange neu startet geht es wieder für eine gewisse Zeit aber die Fehler kommen wieder. Da ist wohl ein Bug drinnen, mit 2008R2 hatte die diese ganzen Probleme noch nie gesehen.

    Hat jemand eine Lösung ?

    Stefan

    Mittwoch, 16. April 2014 18:52
  • Wir reden jetzt aber nicht über Drucker, die über das RDP Protokoll, bzw. Easy Print in die Session kommen, oder?

    Nein, natürlich nicht.


    Nach weiteren Test stellt sich die Situation nun wie folgt dar:

    Nach langen herumprobieren (zunächst auf der alten 2008R2 Farm) stellten wir durch Zufall fest, dass der Aufruf von con2prt.exe /f funktioniert, wenn ein nach einer gewissen "Wartezeit" ausgeführt wird (Der Zufall beruht aufgrund einer gesetzten Pause vor dem Befehl). Die Pause haben wir dann durch eine 10 Sekunden Wartezeit (per Ping) ersetzt -> Jetzt funktioniert es 100%ig.


    Was hier der Grund ist, warum der Befehl ohne Verzögerung nicht funktioniert, ist mir noch ein Rätsel...


    Unter der 2012R2 Farm ist es nun so; dass hier das Löschen und anschließende mappen auch funktioniert (selbes Skript mit Wartezeit), jedoch die "Leichen" anderer Drucker unter "Geräte und Drucker" angezeigt werden; teilweise wird ein und der Selbe Drucker bis zu 5 mal angezeigt. Diese können auch nur mit Admin-Authentifizierung gelöscht werden.


    Was noch interessanter ist: Öffnet man z.B. in Word den Druck-Dialog, werden hier die richtigen Drucker (die auch per Skript gemappt wurden) angezeigt. Die "Leichen" stehen hier nicht zur Auswahl.

    Dieses Drucker Problem bringt uns und unseren Kunden echt zur Verzweiflung. Jahrelang verbinden wir bei all unseren Kunden die Drucker per con2prt und hatten bisher nie Probleme damit. Nach unzähligen Stunden, die wir hiermit verbracht haben, bin ich nun fast erleichtert, dass auch andere Leidgeplagte ihre Erfahungen mitteilen.

    Mittwoch, 16. April 2014 19:32
  • Am 16.04.2014 21:32, schrieb Mark Henkel:

    Wir reden jetzt aber nicht über Drucker, die über das RDP
    Protokoll, bzw. Easy Print in die Session kommen, oder?

    Nein, natürlich nicht.

    War auch nur eine doofe Idee ... :-)

    Nach langen herumprobieren (zunächst auf der alten 2008R2 Farm)
    stellten wir durch Zufall fest, dass der Aufruf von con2prt.exe /f
    funktioniert, wenn ein nach einer gewissen "Wartezeit" ausgeführt
    wird

    Eure Anmeldeprozesse sind synchron? Definiert?
    -> immer auf das Netzwerk warten = aktiviert
    -> Anmeldescripts gleichzeitig ausführen = aktiviert?
       ... wartet bis alle scripte beendet sind bevor explorer.exe startet

    statt con2prt.exe /f sollte auch ein reg del HKCU\Printers\Connections
    und erstellen eines leere HKCU\Printers\Connections klappen.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Mittwoch, 16. April 2014 22:13

  • Nach langen herumprobieren (zunächst auf der alten 2008R2 Farm)
    stellten wir durch Zufall fest, dass der Aufruf von con2prt.exe /f
    funktioniert, wenn ein nach einer gewissen "Wartezeit" ausgeführt
    wird

    Eure Anmeldeprozesse sind synchron? Definiert?
    -> immer auf das Netzwerk warten = aktiviert
    -> Anmeldescripts gleichzeitig ausführen = aktiviert?
       ... wartet bis alle scripte beendet sind bevor explorer.exe startet

    statt con2prt.exe /f sollte auch ein reg del HKCU\Printers\Connections
    und erstellen eines leere HKCU\Printers\Connections klappen.

    Hallo,

    ja, die Anmeldeprozesse sind synchron. Die o.g. Einstellungen kommen auf den Hosts an. Erst nach Abarbeitung des Scripts startet der Explorer.

    Zum Nachvollziehen habe ich bei einigen Mitarbeitern auch eine Pause ins Script gestellt, damit diese die Zuweisung nachvollziehen/prüfen können. Hier ist soweit alles in Ordnung.

    Leider sind nun wieder Probleme aufgetreten. Bei einigen Mitarbeitern wird der Standarddrucker nicht richtig gesetzt, bzw. stellt sich dieser auf einen lokal installierten Drucker um (der lokale Drucker ist ein virtueller Fax-Drucker). Der bei der Anmeldung per Skript gesetzte Standard-Drucker hat also nicht lange Bestand...

    Donnerstag, 24. April 2014 09:04
  • Hi,

    Am 24.04.2014 11:04, schrieb Mark Henkel:

      Der bei der Anmeldung per Skript gesetzte Standard-Drucker hat also nicht lange Bestand...

    An meinem privaten Standalone System (Win8.1) bleibt der Standard Drucker (Brother MFC) nur solange Standard, wie er physikalisch erreichbar ist.
    Sobald ich unterwegs bin, schaltet mein System auf einen lokal vorhandenen PDF Drucker als Standard um, der dann erhalten bleibt.

    Vielleicht ist das gewollt? Damit per Default immer ein Drucker gewählt wird, der auch exisitiert?

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Donnerstag, 24. April 2014 13:52
  • Wir konnten das Problem jetzt vorübergehend "lösen". Das Drucker-Script wird jetzt nicht mehr als Anmelde-Script (über GPO) ausgeführt (vor dem Explorer), sondern im Kontext des Autostarts. Wir haben einfach per GPP eine Verknüpfung zum Script in den Autostart Ordner erstellt.

    Das Script wird nun ausgeführt nachdem der Explorer bereits gestartet ist.

    Sonntag, 27. April 2014 17:57
  • Wir konnten nun feststellen, dass sich der Standard-Drucker nach dem Trennen und anschließenden Neuverbinden einer RDP-Sitzung auf einen lokal installierten Drucker verstellt.

    Diese Tatsache ist leider äußerst ungünstig, da unser Kunde zahlreiche Filial-Standorte hat, bei denen die Internetverbindung nicht besonders stabil ist. Jedes mal wenn die Internetverbindung kurzzeitig ausfällt wird dadurch schließlich die RDP-Sitzung getrennt; nach späteren Neuverbinden haben die User dann einen lokalen Drucker als Standard.

    Hat evtl. noch jemand ein paar Tips für uns??

    Dienstag, 29. April 2014 09:36
  • Am 29.04.2014 11:36, schrieb Mark Henkel:

    nach späteren Neuverbinden haben die User dann einen lokalen Drucker als Standard.

    Was ja eigentlich auch sinn macht, damit der User immer einen verfügbaren Drucker als Standard zum Drucken hat.

    Aber worin liegt das Problem, daß die Leute einfach mal drauf achten wo sie drucken? Die steigen ja auch nicht in ein beliebiges Auto auf dem Parkplatz ein ...

    Ich finde, das es technisch Sinn ergibt, wenn sich der Drucker auf einen verfügbaren umstellt. Das es lästig ist, ist ja der "miesen" Anbindung geschuldet und nicht dem System.

    Bau eine Aufgabe, die die Events 10000 und 10001 des NetworkProfile Protokolls abfängt und dann das Anmeldescript, bzw. den Drucker Connect erneut ausführt.

    Analog zu diesem Beispiel, statt der eigenen EXE das Script hinterlegen.
    http://www.gruppenrichtlinien.de/artikel/proxy-automatisch-an-und-ausschalten-proxy-switcher/

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Dienstag, 29. April 2014 09:53
  • Am 29.04.2014 11:53, schrieb Mark Heitbrink [MVP]:

    Bau eine Aufgabe, die die Events 10000 und 10001 des NetworkProfile Protokolls

    Halt Mist, RDS/TS Sitzung .. da läuft ja keine NLA.
    Dann wirst du einen anderen Event finden müssen, der bei Wiederherstellung auftaucht.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Dienstag, 29. April 2014 10:02
  • > Dann wirst du einen anderen Event finden müssen, der bei
    > Wiederherstellung auftaucht.
     
    Gibt's schon fertig: "Wiederverbinden" :-) Aber Achtung: In einem Task
    mit diesem Event ist %clientname% nicht verfügbar, falls das benötigt
    werden sollte...
     

    Martin

    Mal ein GUTES Buch über GPOs lesen?

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    And if IT bothers me - coke bottle design refreshment :))
    Dienstag, 29. April 2014 16:55
  • Hallo Mark,

    wir haben exakt die gleichen Probleme, daher meine Frage gibt es  in der Zwischenzeit eine Lösung.

    Danke für die Rückmeldung

    mfg


    P.P.

    Montag, 2. März 2015 13:14
  • dieses Verhalten kann durch folgenden Eintrag in der Registry unterbunden werden.

    Computerkonfiguration:

    Aktion: Aktualisieren

    HKEY_LOCAL_MACHINE
    SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider
    RemovePrintersAtLogoff

    REG_DWORD
    00000000


    P.P.

    Dienstag, 3. März 2015 10:18
  • Herzlichen Dank Mr. Pichler

    Habe mich 4 Tage lang dumm und dämlich gesucht und stundenlang rumprobiert.

    Ihr Registry-Eintrag war die Lösung.

    Ich kann beim besten Willen nicht nachvollziehen, wieso Microsoft den nicht von Haus aus setzt, zumal Druckerverbindungen bei Remote Desktop Session Hosts (Terminalservern) ohne diesen Eintrag partout nicht zuverlässig funktionieren, weder mit Server 2012 R2 noch mit Server 2016.

    Nach 4-tägiger Internetsuche scheint es klar zu sein, dass unzählige Administratoren mit den gleichen Problemen kämpfen und viele davon entnervt aufgeben, oder Skripts schreiben, um täglich die durch das Printerlogoff verursachten Registryfehleinträge zu löschen. Alles in allem wohl unzählige verschwendete Stunden, nur weil Microsoft seit Jahren diesen Key nicht setzt...


    • Bearbeitet MatRom Montag, 11. September 2017 14:02
    Montag, 11. September 2017 14:01
  • Bitte - freut mich das Sie ihr Problem lösen konnten

    P.P.

    Dienstag, 12. September 2017 09:12