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)

veritas backup exec 10, da gibts den noch nicht :)

das is natürlich kein ersatz für ein normales backup. exchange-postfächer werden über den backup exec agent seperat rausgesichert. Dateien hol ich mir sofern möglich über schattenkopien zurück oder ich mounte kurzfristig die gesicherte vhd-file. Aber die wichtigen Daten liegen eh nicht auf virtuellen Platten sonderm aufn NAS, welches auch seperat gesichert wird. mit meinem script mach ich halt zusätzlich ein komplett-backup der virtuellen Platten (eignet sich eher für disaster recovery)

ich habe mir hierzu (unter server 2008) ein script gebastelt welches folgende aktionen ausführt: virtuelle server werden sauber heruntergefahren Status wird mit einem simplen "ping" überprüft die VHD-Files werden auf das NAS kopiert virtuelle Server werden wieder gestartet Status wird mit einem simplen "ping" überprüft Mail an mich (über sendmail) die VHD-Files werden vom NAS auf Band gesichert Das ist zwar nicht sonderlich originell und sauber, aber funktioniert nun seit fast 3 Jahren anstandslos :)

Mich würde dabei interessieren, ob MS da zwischen "Backups die erst eingespielt werden müssen" und "Bereits wiederhergestellte Backups, welche im Bereitschaftsmodus rennen" differenziert. Logisch Die virtuellen Server sind zw. den ESX-Hosts aufgeteilt. Eine Hälfte hostet der ESX-1, die andere der ESX-2. Ein zugehöriges Replikat der Server steht dem jeweils gegenüberliegenden ESX-Host zur Verfügung (inaktiv). Im Ernstfall kann zwar ein ESX die gesamte Last verkraften, allerdings führt der dann ein Leben am Limit :) Brauche ich also so schnell wie möglich nach einem Ausfall wieder die Lastenaufteilung, benötige ich scheinbar auch die zusätzlichen Lizenzen. Inwiefern kann ich in diesem Anwendungsbeispiel die Neuzuweisung innerhalb der 90 Tage-Frist durchführen? Auch wenn der ESX1-Server komplett ausgetauscht wurde, sind die Server-Lizenzen nach wie vor an dem ESX2 gebunden, oder stehe ich hier aufn Schlauch? Edit: wurde von lizenzdoc im posting ober mir beantwortet :)

sehr fein. D.h. in meinem Szenario ist ein sperren oder entfernen von Lizenzen eh irrelevant, da es sich ja um ein und demselben virtuellen Server handelt (die virtuelle Festplatte wird nachdem ESX-1 kaputt ging auf ESX-2 "eingehängt"). Ärgerlich dabei ist nur, dass (zumindest lizenztechnisch) 90 Tage keine Redundanz besteht (selbst wenn ESX-1 wieder voll funktionsfähig wäre, dürfte ich die VMs vor Ablauf der Frist dort nicht starten). Aber is das wirklich von MS so angedacht? 1. Beispiel 01.01.2013 - ESX-1 fällt aus, alle Server werden von ESX-2 gehostet. 03.04.2013 - Server werden von ESX-2 auf ESX-1 zurückübertragen - alles in Butter 2. Beispiel 01.01.2013 - ESX-1 fällt aus, alle Server werden von ESX-2 gehostet. 01.02.2013 - ESX-1 fällt schon wieder aus. Nicht tragisch, da eh ESX-2 die Server bereitstellt. 01.03.2013 - ESX-1 fällt ein drittes Mal aus, diesmal wird das Teil komplett getauscht 03.04.2013 - Server werden von ESX-2 auf ESX-1 zurückübertragen - alles in Butter 3. Beispiel 01.01.2013 - ESX-1 fällt aus, alle Server werden von ESX-2 gehostet. 01.02.2013 - ESX-2 fällt aus: Alle Windows Lizenzen müssen ein weiteres Mal erworben werden, um die Teile wieder auf ESX-1 betreiben zu dürfen. 02.02.2013 - egal, kann ab nun die platten zw. den ESX-Servern rumschieben wie ich lustig bin

Vielen Dank für die ausführliche Antwort. Kann ich daraus schliessen, dass es ausreicht jeweils 1x ESX-Host für MS Produkte zu lizensieren, sofern ich im Ernstfall nach der Wiederherstellung auf dem 2. ESX-Host die Lizenzen neu "zuweise"? (also auch 90 Tage den virtuellen Server auf diesem ESX-Host belasse). Das Teil soll halt nur im Ernstfall einspringen. Ein verschieben der virtuellen Servern zw. den beiden ESX-Hosts aus z.B. Performance-Gründen findet nicht statt. Oder reicht allein schon die technische Möglichkeit dazu aus, die Lizensierung des zweiten ESX-Hosts zu verpflichten?

Danke für die Antwort Ja, das Netzteil vom physischen "Bereitstellungsserver" ist aktiv. Allerdings befinden sich die virtuellen Replikas nicht direkt auf diesem Server, sondern auf einem NAS wo beide ESX-Server Zugriff haben. Im Ernstfall wird nur die VM-Config mit Pfadangabe zum NAS von z.B. ESX1 auf ESX2 verschoben (das rennt halt weitgehend automatisch ab). Was verhält es sich z.B. in folgendem Szenario: Ich habe einen physikalischen Server firsch vom Hersteller, ohne OS und einsatzbereit. Ich installiere nun auf diesen Server direkt einen Windows Server 2003 Standard. Nach Fertigstellung erstelle ich ein Image der Systempartition (z.B. mit Ghost oder Acronis) und speichere dieses auf einer usb-Festplatte. Nach Jahren geht das Motherboard kaputt. Um die Downtime so kurz wie möglich zu halten renne ich in den Keller und hole einen "alten" Power-PC rauf. Auf diesem stelle ich das damals erstellte Server-Image wieder her und richte manuell die 2-3 Dienste wieder ein, um das Teil lauffähig zu bekommen. Nachdem ich Tage später den kaputten Server wieder lauffähig bekommen habe, mache ich das Ganze rückgängig. Benötige ich auch hierfür eine zusätzliche Server 2003 Lizenz? Zugegeben, vielleicht nicht der beste Vergleich, aber ich glaube man kann erkennen, worauf ich hinauswill :) Mit SA sollte der EInsatz eines Cold-Server doch eh abgedeckt sein? Zumindest lese ich das so aus dem SA-Programm raus. SA = Ich darf Cold-Backup/Cold-Standby Server betreiben, und diese sind auch mit den Lizenzen abgegolten, sofern ich die Serverlizenzen und auch die Client-CALs über SA erworben habe. kein SA = ich benötige für jeden Cold-Backup Server eine eigene Lizenz. Edit: Hab nochmal drübergelesen. Der springende Punkt ist also die Tatsache, dass der "Bereitstellungsserver" so oder so keinem Cold-Backup entspricht und auf jeden Fall, egal welche Lizenzierungsform man wählt, seperat lizensiert werden muss. Den ganauen Sachverhalt inkl. Beispiel habe ich hier auf Seite 11 gefunden: http://download.microsoft.com/download/6/8/9/68964284-864d-4a6d-aed9-f2c1f8f23e14/virtualization_whitepaper.doc Nur damit ich das richtig verstehe: Ich habe z.B. ein SAN mit 5 virtuellen HDD´s (Server 2003 + Exchange); für das (linux)SAN oder die virtuellen HDDs werden keine Lizenzen benötigt. Nun habe ich 1x VM-Server, lizensiert mit 1x Server 2003 und 1x Exchange, darauf ist eine virtuelle HDD aus dem SAN eingebunden, alle Lizenzen sind damit aufgebraucht. Habe ich nun einen 2. VM-Server für die Wiederherstellung, benötigt auch dieser jeweils eine Server 2003 + Exchange Lizenz, wenn ich eine der 5 HDD´s dort in Betrieb nehmen möchte. Solange der zweite Server nicht über die Lizenzen verfügt, darf darauf keine Wiederherstellung erfolgen. Entspricht das i.e. den Tatsachen?

hallo leute, ich habe die suchfunktion hier im board und auch google intensiv bemüht, bin aber trotzdem nicht so recht fündig geworden. Mir stellt sich die Frage, ob Offline-Replikate von virtuellen Servern von MS als "Cold-Backups" definiert werden. MS sagt hierzu folgendes: Microsoft definiert einen Cold Server als einen Server, der bis zum Eintritt eines Notfalls ausgeschaltet ist. Der Server steht in keiner Produktiv-Umgebung und es findet keine Datenverarbeitung auf ihm statt. Bei Eintritt eines tatsächlichen Notfalls, kann der Cold Server (Sicherungsserver) für die Wiederherstellung des Produktionsservers verwendet werden. Software Assurance Services für Forschung & Lehre Ich interpretier das folgendermaßen: Ein Cold-Backup Server wird frisch installiert und für den Ernstfall vorbereitet (Wichtige Dienste u. Anwendungen werden im Vorfeld installiert). Tritt der Ernstfall ein, wird das Gerät fertig installiert u. konfiguriert um alle relevanten Dienste vom ausgefallenen Server zu übernehmen. Das Gerät ist ansonsten immer ausgeschalten und wird lediglich für Updates oder Nachjustierungen "kurz" aktiviert. Doch wie verhält sich das bei virtuellen Replikas? Beispiel-Szenario Server 1 - VMWare ESX mit 2x Windows Server 2003 Std. Server 2 - VMWare ESX mit einem Replikat der 2 2003-Server von Server1 Die Replikation wird mit vRanger/vReplicator durchgeführt. Die Replikate auf Server2 sind nicht aktiv. Nur im Notfall (Server 1 fällt aus) soll Server2 die Replikas bereitstellen. Genau genommen, handelt es sich um ein Backup (von der kompletten virtuellen Maschine), welches im Ernstfall schnell angestartet werden kann. Mich würde interessieren, ob MS diese "Backups" bereits als Cold-Backup definiert, und somit zusätziche Lizenzen oder ein Lizenzvertrag mit Software-Assurance notwendig wird. Wenn dem so ist, frage ich mich wo genau der lizenztechnische Unterschied zu z.B. einer Backup-Exec Komplettsicherung inkl. Systemstate besteht. Wäre toll, wenn hier jemand etwas Licht ins Dunkel bringen könnte

imho kann man jedes vista image auf jeden beliebigen rechner aufspielen solange die mindestvoraussetzungen der hardware eingehalten werden. Also 32bit -> 32bit und 64bit -> 64bit.

Habe in meiner Testumgebung Exchange 2007 mit SP1 installiert und sämtliche Öffentliche Ordner vom Exchange2003 übernommen (ohne powershell; publicfolders in pst exportiert und unter exch2007 wieder importiert). Kalender und mailaktivierte öffentliche ordner funktionieren einwandfrei - und ich kann nicht ganz nachvollziehen, warum MS wieder Abstand von den publicfolders nehmen will (wo es doch gerade in exch2003 massiv bworben wurde). Da ich nur kleine Unternehmen betreue, ist der Einsatz von Sharepoint nicht wirklich akzeptabel (zu hohe Anschaffungskosten und Anforderungen an Hardware und Administration). Ich persönlich werde auch weiterhin öffentliche Ordner in Produktivumgebungen einsetzen (was ja unter exch2007 SP1 bedingt noch unterstützt wird), eben genau wegen der allgemein zugänglichen "INFO@-Adresse" und einem bereitgestellten Kalender. Ausserdem können Kunden ohne WindowsMobile Handy die öffentlichen Ordner via. IMAP abrufen.