sheeva

Hier das Script: <# $printserver = "FQDN des Printserver" $defaultPrinter = gwmi win32_printer | where {$_.Default -eq $true} Get-WMIObject Win32_Printer | where{$_.Network -eq 'true'} | foreach{$_.delete()} $printerlist = Get-WMIObject -Class Win32_Printer -Computer $printserver ForEach ($printer in $PrinterList) { (New-Object -Com Wscript.Network).AddWindowsPrinterConnection("\\$printserver\" + $printer.sharename) } $defaultPrinter.SetDefaultPrinter() > Damit das Script für normale User (ohne Admin-Rechte) funktioniert, benötigen diese noch die Berechtigung für Remote WMI-Abfragen (wird am Printserver gesetzt). Hier eine Anleitung: http://serverfault.com/a/44997

Das war auch mein Gedanke und habe extra für die Printserver-Rolle einen 2008R2 bereitgestellt. Leider traten die Probleme nach wie vor auf (PDFs konnten teilweise nicht ausgedruckt werden, Standarddrucker wurde manchmal nicht gesetzt, Drucker verschwanden willkürlich aus der Druckerliste des Users, etc.). Schuld ist der Client (Server 2012R2 RDS-Host) und nicht der Printserver. Ich habe nun die Durckerverteilung via. GPP auf ein Powershell-Logonscript umgestellt. Standarddrucker wird ausgelesen und in einer Variable gespeichert Alle Netzwerk-Drucker werden gelöscht Alle Drucker am Printserver werden via WMI ausgelesen und den User eingebunden. Standarddrucker (1.) wird wieder gesetzt Kann das komplette Script bei Bedarf gerne posten. Bisher konnte ich noch keine der o.g. Probleme feststellen.

kämpfe schon seit über einen jahr mit den von dir geschilderten problemen. seit der umstellung der terminalserverumgebung auf server2012 r2 verzeichne ich auch regelmäßig: standarddrucker verschwindet fehler beim ausdruck von pdf-files manchmal werden nicht alle drucker eingebunden dabei spielt es keine rolle, ob die drucker über logonscript, gpo, gpp oder sonstwie eingebunden werden. die probleme treten früher oder später immer wieder auf. habe auch sämtliche vorschläge in den von dir geposteten link (teilweise mehrmals) abgeabreitet - leider ohne langfristigen erfolg. zuletzt habe ich die printserver rolle einem frisch installierten server2008r2 zugewiesen - doch auch das brachte nurz kurzfristig besserung. zwischenzeitlich habe ich die drucker für mehrere monate lokal auf den RDS-Hosts installiert. Dies lief ohne Probleme, allerdings will ich eine zentrale Druckerwarteschlange u. Standardeinstellungen für Drucker nicht wirklich missen. Als Workaround lösche ich das Roaming-Profile vom User wenn er Probleme mit den Druckern hat. Nach Neuanmeldung funktionierts dann wieder eine zeitlang. Leider treten die Probleme komplett willkürlich auf und lassen sich auch nicht reproduzieren. Das Setzen der ganzen Registry-Keys u. die Bereinigung der Print-Treiber hat definitiv Besserung gebracht. Aber die Fehler sind nicht weg - sie treten nur seltener auf.

hast du den lösungsvorschlag von mad1812 schon ausprobiert? https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2129176

Korrekt! Auch ich habe sämtliche in diesen Thread vorgeschlagenen Lösungsansätze durchgearbeitet. Manchmal war dann auch ein paar Tage alles in Ordnung, aber irgendwann sind wieder die von dir geschilderten Probleme aufgetaucht. Leider fand ich auch keine Möglichkeit die Probleme irgendwie gezielt zu reproduzieren und so war auch nur sehr oberflächliches Troubleshooting möglich. Irgendwann hab ich kapituliert u. die Drucker alle lokal auf den Terminalservern installiert. Das ist zwar nicht wirklich hübsch und verwaltungstechnisch bissl aufwendig, aber zumindest gibts nun seit mehreren Monaten keine Probleme mehr.

Wir haben eine ähnliche Anforderung folgendermaßen gelöst: Netz1: Domänen-Netz, normale Daten, Internetzugriff Netz2: Arbeitsgruppen-Netz, sensible Daten, kein Internetzugriff Anforderung: sensible Daten, welche in Netz2 erstellt werden, müssen teilweise von einem Programm in Netz1 weiterverarbeitet werden. Die beiden Netze sind über eine Firewall miteinander verbunden. In beiden Netzen gibt es einen Fileserver. Netz2-Fileserver hat Zugriff auf Netz1-Fileserver Netz1-Fileserver hat keinen(!) Zugriff auf Netz2-Fileserver Alle anderen Zugriffe zw. den Netzen sind geblockt. Die Daten, welche in dem "Export-Ordner" auf Netz2-Fileserver landen, werden über einen geplanten Task regelmäßig auf ein Share in den "Import-Ordner" auf Netz1-Fileserver kopiert/verschoben. Über FSRM wird noch zusätzlich reguliert, welche Dateien überhaupt auf dem Netz1-Fileserver abgelegt werden dürfen. Wär halt gut zu wissen, was genau du erreichen willst

Das hat leider auch nur temporär was genützt. Nach ein paar Tagen fingen die Probleme wieder an. Aktuell sind bei mir immer noch alle Drucker auf allen RDS-Hosts lokal installiert. Wartungstechnisch zwar ein Alptraum da die Druckerwarteschlange nicht zentral aufrufbar ist, aber wesentlich weniger Aufwand als das permanente Troubleshooten des Printservers, restarten des spoolers, neuverbinden von Druckern, etc. Ich hab die Flinte mittlerweile ins Korn geworfen und warte auf Server 2016 bzw. einen Hotfix von MS, welcher das Problem explizit adressiert. Bin da aber nur noch mäßig optimistisch

korrekt ich habe das über folgendes powershell-script gelöst, welches über einen geplanten task täglich um 4:00 morgens ausgeführt wird: #geplanter task auf den ts-servern #auszuführender account:SYSTEM (lokal) #Programm:C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe #Argument:\\Pfad_zum_script\ts_dailyprintdelete.ps1 #Zeitplan: täglich um 4:00 Remove-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\*" -Recurse restart-service spooler -force

Hallo Zusammen Will mich auch nochmal bzgl. der Druckerproblematik melden. Wir haben in den letzten 3-4 Monaten sämtliche Empfehlungen und Tipps hier im Thread ausprobiert, allerdings hatte nichts davon nachhaltigen Erfolg. Früher oder später hatten wir wieder das Problem, dass Anwendungen keine Drucker fanden bzw. die Drucker vielfach in der Druckerverwaltung angezeigt wurden. Da wir letztendlich keine zufriedenstellende Lösung finden konnten, haben wir die Drucker auf den RDS-Hosts (2012 R2) nun wieder lokal installiert. Dies ist zwar mühsam zu verwalten u. viele Features (globale Druckereinstellungen, einheitlicher Spooler für alle User, etc.) vermissen wir zwar, aber zumindest gibt es nun seit mehreren Wochen keine technischen Probleme mehr. Ich für meinen Teil habe mich damit jetzt erstmal abgefunden, und will auch nicht zukünftig für jeden Regkey der vielleicht(!) das Problem behebt wieder einen Printserver in Betrieb nehmen und sämtliche Drucker für alle User neu ausrollen. Zumindest nicht solange MS das Problem nicht öffentlich adressiert und Lösungsvorschläge anbietet.

ich habe die anleitung vor mehreren wochen penibel abgearbeitet. allerdings brachte das nur für ein paar tage besserung. @twenty kannst du nochmal kurz rückmelden, ob die 2 regkeys das problem bei dir lösen konnten? die keys werden vermutlich auf den terminalservern gesetzt? über welche methode werden die drucker bei dir eingebunden (logonscript, gpo, gpp)? lg sheeva

hat schon jemand neue Erkentnisse bzgl. der Druckerprobleme? Seit meinem letzten Beitrag hatte ich keine Probleme mehr mit der lokalen Druckerinstallation. Mittelfristig würde ich aber doch gerne wieder auf einen Printserver zurückgreifen

kann ich auch bestätigen - nach lokaler Installation der drucker auf den rds-Hosts sind alle Probleme beseitigt. da ich fast 30 drucker auf 4 rds-Hosts installieren musste, hab ich diese über ein powershell-script ausgerollt. die druckernamen u. verwendeten treiber (müssen auf dem rds-Hosts vorinstalliert werden) hab ich in eine csv-Datei eingetragen. da ich sämtliche drucker auch im DNS eingetragen habe, konnte ich als hostadresse den druckernamen angeben. Printer.csv: name;driver; drucker01;Lexmark Universal v2 XL; drucker02;Xerox Phaser 6180MFP-D PCL 6; usw. Printer.ps1 $printers = Import-Csv -Delimiter ";" -Path "printer.csv" -Encoding UTF8 foreach ($printer in $printers) { $printername = $printer.name $driver = $printer.driver 　 add-printerport -name $printername -printerhostaddress $printername add-printer -name $printername -drivername $driver -port $printername } evtl. hilfts ja jemanden

ich habe leider ähnliche probleme wir wollten von ts 2003 (printserver 2008) auf ts 2012r2 (printserver 2012r2) migrieren. unter 2003 hat alles relativ problemlos funktioniert - unter 2012r2 häufen sich nun die probleme mit den druckern. mehrfache anzeige der drucker in der systemsteuerung standarddrucker-häckchen verschwindet willkürlich drucken aus ms word oder anderen anwendungen (adobe reader z.B.) nicht möglich Unter Systemsteuerung>Geräte und Drucker wird ein Wirrwarr an Druckern aufgelistet. Doppelte Einträge, manchmal der Drucker in Großbuchstaben u. manchmal nicht, "Geist-Drucker" vom alten Printserver, etc. Die meisten Ghost-Drucker kann ich dann per Hand löschen, bei anderen hingegen klappt das nicht mit der Meldung "unzureichend Rechte" (trotz Admin Konto). Unter der alten klassischen Druckeransicht (aufrufbar über den Pfad C:\Windows\explorer.exe /e,::{2227A280-3AEA-1069-A2DE-08002B30309D}) sieht hingegen alles i.O. aus. Keine doppelten Einträge oder ähnliches, aber die o.g. Probleme bestehen leider trotzdem. ich habe so ziemlich alles ausprobiert was hier im thread und auch sonst unter google zu finden ist. wenn ich die RDS-Hosts komplett von allen Druckern bereinige (treiber löschen, registry-pfade ausmisten, etc.), dann funktioniert es auch wieder eine zeit lang. aber die probleme kommen früher oder später trotzdem wieder. Folgende Aktionen konnte die Probleme wenigstens für ein paar Tage eindämmen: http://digitalzombies.com/2014/07/03/print_issues_rds_2012/#resolution ich kann die o.g. probleme auch nciht gezielt reproduzieren; die treten komplett willkürlich bei unterschiedlichsten benutzern auf. auch habe ich die einbindung der drucker sowohl über GPP, GPO u. logon-scripts versucht - leider alles ohne erfolg. spiele nun auch mit dem gedanken die drucker lokal auf den RDS-Hosts zu installieren :/

ich weiss nicht, ob das auch beim sbs2011 relevant ist, aber unter sbs 2003 hatte ich öfters das problem, dass die ports fürn rpc-proxy nicht richtig gesetzt wurden (was geschehen sollte, sobald man den exchange-server als rpc-backend einrichtet).  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy  ValidPorts: ServerNETBIOSName:6001-6002;ServerFQDN:6001-6002;ServerNetBIOSName:6004;ServerFQDN:6004 (Defaultwert für RpcProxy lautet: ValidPorts: ServerNETBIOSName:100-500) musste das schon mehrmals per hand korregieren. ansonsten start mal outlook mit dem parameter "/rpcdiag".

banal, aber doch oft gerne übersehen: die jeweils benutzerabhänigen Einstellungen für den Bildschirmschoner (Kennworteingabe bei Reaktivierung)