Monat: April 2015

Problem

Der Adobe Reader XI druckt auf Terminal Servern keine PDF-Dateien mehr aus sondern vermeldet bockig „Das Dokument konnte nicht gedruckt werden“ und/oder „Es wurde keine Seiten zum Drucken ausgewählt„. Das Phänomen tritt unter Windows Server 2008/R2 und Server 2012/R2 auf, sowohl auf Terminalservern (RDS) als auch in einem „Admin Only“ Account. Grundsätzliche liegt das an gewissen Schwächen des Adobe Readers in Mehrbenutzerumgebungen, die sich öfters bei Treibern zeigen, deren Entwicklungszeil ebenfalls kein Mehrbenutzersystem war. Also praktisch alle Treiber außer „Universal“ Treibern.

Lösung

In den meisten Fällen hat es uns geholfen, die Druckertreiber auf dem Printserver im Isolierten Modus auszuführen, die Clientseitige Druckaufbereitung zu deaktivieren (was bei Terminalservern grundsätzlich der Fall sein sollte) und den Druckprozessor zurück auf den Standardmäßigen WINPRINT zu stellen.

Manchmal hilft es, nur die Verbindungsschlüssel für den Betroffenen Benutzer zurpückzusetzen. Das ist aber kein Allheilmittel.

reg delete "hkcu\printers\connections" /f

Druckertreiber im Isolierten Modus ausführen (für RDS sowiso empfohen)

1. Druckverwaltung öffnen und mit dem jeweiligen Printserver verbinden
2. Zu „Treiber“ wechseln, Drucker markieren
3. Rechte Maustaste „Treiberisolation festlegen“ > „Isoliert“

Clientseitige Druckaufbereitung deaktivieren

 

1. Druckverwaltung öffne, zu „Drucker“ wechseln
2. Eigenschaften des Druckers, Tab „Freigabe“
3. „Druckauftragsaufbereitung auf Clientcomputern durchführen“ deaktivieren
4. Bei allen betroffenen Druckern wiederholen

Druckprozessor auf WINPRINT zurücksetzen

1. Auf dem betroffenen Druckserver die  Drucker auf den WinPrint Prozessor zurücksetzen. Dafür ALS ADMIN an der Powershell ausführen:

   set-itemproperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\Print\Printers\*' -name 'Print Processor' -value WinPrint

2. Auf dem betroffenen Druckserver die  TREIBER auf den WinPrint Prozessor zurücksetzen. Dafür ALS ADMIN an der Powershell ausführen:

   32bit (x86)

   set-itemproperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\*' -name 'Print Processor' -value WinPrint

   64bit

   set-itemproperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\*' -name 'Monitor' -value $null

Ein risige Dankeschön an „aardum“ für seinen Ausführlichen Artikel in seinem Blog. Der Mann weiss wovon er spricht, bei interesse ist ein Blick in seinen Bericht empfehlenswert.

Problem

Ein Programm bring einen Prozess mit, der immer laufen muss, wie ein Dienst. Leider hat der Programmierer die Dokumentation zu Windows-Services nicht gelesen (oder verstanden) und hat eine Desktop-Applikation gebaut. Jetzt muss der Server-Desktop immer angemeldet sein, damit der „Dienst“ läuft.

Das kommt (leider immer noch) in verschiedenen Fällen vor. Es gibt tatsächlich auch heute noch Unternehmen die glauben „einen viel besseren Webserver“ schreiben zu können oder eine Philosophie vertreten wie „Einen Webserver brauchen brauchen wir nicht, das kann die Software von selber“. Dieser technisch höchstkompetenten Ansage kann man als Admin weder mit Fakten noch Argumenten beikommen, für einige Programmierer existiert nur der Desktop und nichts weiter.

Lösung

Admins to the rescue. Neben SRVANY, ServiceDemon und ähnlichen dreiviertelguten Ideen gibt es den NSSM – den „Non Sucking Service Manager“. Als eins der vermutlich besten Programme der aktuellen Windows-Admin Toolwelt kann der NSSM praktisch beliebige Programme als Dienst starten.

Das klappt ausgezeichnet mit Konsolenfenstern, Windows-Applikationen, Batchdateien, Datenbanken, Telekom-Telefonbüchern, Webbrowsern … praktisch allem. Das Tool kann auf einfachste Art dem Programm geben was es braucht (Logon-ID, Desktopsession, Pfade …) und stellt die Zwischenschischt zum Servicemanager dar. sogar Benutzerdefinierte Beendigungs-Parameter sind möglich, wie CTRL+C oder ALT+F4, bis hin zum einfachen Prozess beenden.