File Share Scoping

Bei Windows Server 2008 wurde eine Funktion namens File Share Scoping implementiert, die es verhindert, dass Dateifreigaben über unterschiedliche Zugriffspunkte (Client Access Point – CAP) erreichbar ist. So war es in der Vergangenheit möglich über den Namen des lokalen Knotens, die IP Adresse des Knotens auf eine Freigabe zuzugreifen, allerdings immer nur auf dem aktiven Knoten. Waren die Ressourcen auf Grund eines Failovers auf den anderen Knoten geschwenkt, dann lief der Zugriff über den UNC Pfad oder die IP in’s Leere. Dieses Verhalten wurde eben ab Windows Server 2008 entfernt, um den unerwünschten Effekt zu verhindern.
Leider führt das bei vielen Muktifunktionsgeräten (MuFu oder Multifunctional Printer/Peripheral MFP) dazu, dass diese nicht mehr auf eine geclusterte Dateiablage scannen können – viele dieser MuFus nutzen für die Ablage von Scandokumenten ‚rein die IP Adresse und können dazu nicht den Namen verwenden. Hier sind mir Probleme im Zusammenhang mit Ricoh, Xerox sowie Konica Minolta Multifunktionsgeräten bekannt. Es gibt hierfür keine Lösung außer der Hersteller des Geräts bietet eine bereinigte Firmware, die die Korrekte Adressierung einer Freigabe über einen UNC Pfad ermöglicht oder man aktualisiert den Cluster auf Windows Server 2012 oder neuer.
Für Xerox MFPs gibt es in diesem Artikel einen Beitrag, der auch das Verhalten beschreibt, mit einem Workaround:
» http://social.technet.microsoft.com(…)e44fef44-8742-449e-a829-1ccf61689342/

Das Thema File Share Scoping wird in diesem TechNet Blogartikel im Detail beschrieben:
» http://blogs.technet.com/b/askcore(…)
Für Windows Server 2012 oder neuer ist die Möglichkeit über eine SMB Alias Funktionalität wieder gegeben, so dass man über CNAMEs oder IPs auf einen Cluster Share zugreifen kann, siehe: » http://blogs.msdn.com/b/clustering/archive/2012/04/08/10291792.aspx

Stay tuned,
N.Own

Print Cluster Best Practices

Auf dem Microsoft Blog des AskPerf Teams ist kürzlich ein neuer Artikel zum Thema „Windows Print Cluster Best Practices for Windows Server 2003 to Windows Server 2008 R2“, den ich jedem Print Cluster Admin an’s Herz legen kann:

» http://blogs.technet.com/askperf/print-cluster(…)

Die Empfehlungen decken sich mit meinen Erfahrungen bei Print Clustern aus dem Artikel » Print Cluster 101

Beim Troubleshooten sollte man zuerst die o.g. Punkte prüfen, um sicherzugehen, daß nicht grundlegende Spooler Fehler im Cluster die Probleme verursachen.

Stay tuned,
N.Own

IT-Administrator Ausgabe 08/09: Hochverfügbarkeit

Diesmal ein Beitrag in eigener Sache:
In der aktuellen Ausgabe des IT-Administrator zum Thema Hochverfügbarkeit findet man u.a. einen Artikel von mir:

Hochverfügbarkeit mit Windows Server 2008 R2 – Virtuelle Clusterfreuden“ (N.Own)

Der Artikel behandelt die neuen Clustering Features der R2 Version: Cluster Shared Volumes (CSV) in Verbindung mit Hyper-V und dessen Funktionsweise, SAN Fault Tolerance, erweiterte Failover Cluster Validation, Printer Driver Isolation (cluster aware) und das Tool Print Backup Restore Manager (PrintBRM):

http://www.it-administrator.de/magazin/(…)63358.html

Aber es sind noch mehr interessante Artikel in der Ausgabe zum Thema Hochverfügbarkeit:
http://www.it-administrator.de/magazin/(…)200908.html

Den IT-Administrator gibt es ab morgen, Montag den 03.08.09, am Kiosk.

Stay tuned,
N.Own

Printer Driver Isolation

Windows Server 2008 R2 bringt ein neues Feature mit, das Print Cluster Administratoren zu schätzen wissen werden: Printer Driver Isolation – Sandboxing für Druckertreiber.

Damit ist es möglich einzelne Druckertreiber in eigenen Prozessen laufen zu lassen, ohne das der Spooler bei Absturz dieser davon betroffen ist. Die Druckjobs sowie andere Druckprozesse bleiben davon ebenfalls unberührt.

Es gibt dazu drei Modi, die für einzelne Druckertreiber ausgewählt werden können:

  • None
  • Shared
  • Isolated

None entspricht der Einstellung unter Windows Server 2003: Der Druckertreiber läuft im Kontext des Spoolers. Im Shared Modus laufen die Druckertreiber unabhängig vom Spooler Prozess in einem eigenen Prozess (PrintIsolationHost.exe), die Treiber teilen sich einen Host Prozess.
Im Isolated Modus können einzelne Druckertreiber in eigenen Prozessen ausgeführt werden – sowohl unabhängig vom Spooler als auch von den Host Prozessen der anderen Druckertreiber. Letzteres bietet sich für vor allem für problembehaftete Druckertreiber mit bekannten Problemen an.

Printer Driver Isolation

Mittels Printer Driver Isolation unter R2 kann ein fehlerhafter Druckertreiber nicht mehr die Verfügbarkeit des Print Clusters an sich beeinträchtigen.

Siehe auch:
» http://msdn.microsoft.com/en-us/library/dd568151.aspx

Stay tuned,
N.Own

PRINTBRM löst PrintMig ab

 align=Der Print Migrator war das Tool der Wahl zum Backup & Restore sowie zur Migration von Druckern auf Windows Servern und Windows Print Clustern.

Unter Windows Server 2008 / 2008 R2 gibt es ein neues Tool neben der PMC GUI, das sich für diese Zwecke anbietet: PrintBRM.exe (Print Backup Restore Manager).

» http://support.microsoft.com/kb/938923/en-us

Es wird im Gegensatz zum PrintMig unter x64 Systemen supported:

Weiterführende Informationen zu PrintBRM sind u.a. hier zu finden.

» AskPerf: Why PrintMig 3.1 is Retired

» AskPer: PRINTBRM and the Configuration File

Wie erwähnt kann auch der Printer Migration Wizard der Print Management Console (PMC) über die GUI genutzt werden. PrintBRM kann über den Switch -c parametrisiert und zB. für eine regelmäßige Sicherung mittels Script genutzt werden.

Stay tuned,
N.Own

Print Cluster 101

Ein Print Cluster bietet einem eine gute Möglichkeit erhöhte Ausfallsicherheit für Druckdienste zu erreichen. Dabei kann auch einiges schiefgehen, wenn die Druckertreiber nicht standardkonform sind oder Komponenten wie der Print Prozessor oder Print Monitor des Druckertreiberherstellers Probleme bereiten.

Auch wenn der Cluster sauber arbeitet ist eine Überprüfung des Spooler lohnenswert, beim Troubleshooting hat man die Infos schneller zur Hand und weiß sofort wo man hingreifen muss.

Interessant auf einem Standalone Server (ohne Cluster) sind die folgenden Speicherorte von Druckertreibern:
Registry: HKLM\SYSTEM\CurrentControlSet\Control\Print
File: %SYSTEMROOT%\system32\spool (default)

Registry: Bei einem Print Cluster ist der Registryzweig hier zu finden:
HKLM\Cluster\Resources\<GUID>\Parameters
Die Zuordnung der GUIDs zu den entsprechenden Ressourcen sind in folgendem Zweig hinterlegt:
HKLM\Cluster\Resources

Die Print Spooler Files befindet sich auf dem SharedDevice im Verzeichnis Spool, dieser Speicherort ist frei wählbar. Die Daten liegen ebenso im lokalen Spoolerverzeichnis des Nodes unter:%SYSTEMROOT%\system32\spool\drivers\<GUID>

In den Verzeichnissen Monitors, PRTPROCS sind die entsprechenden Print Monitore und Print Prozessoren des Treibers abgelegt.

Generell sollte man darauf achten auf einem Windows Server 2003 System nur Level-3 Druckertreiber einzusetzen, da es sich hierbei um User Mode Treiber handelt. Level-2 Druckertreiber sind Kernel Mode Treiber, die bei einem Problem das gesamte System zum Absturz bringen können.
Soweit möglich sind Inbox Treiber den Druckertreibern der jeweiligen Hersteller vorzuziehen.

Weiterführende Links:
» KB278455: How to set up a clustered print server
» KB302539: How to Troubleshoot Printing Issues on a Cluster

Stay tuned,
N.Own