IPSec auf einem Windows Server 2003 Cluster?

IPSec war von Microsoft mit Erscheinen von Windows Server 2003 ursprünglich als not recomended für den Clusterbetrieb eingestuft:

» TechNet: IPSec in Cluster Networking
(Stand: January 01, 2003)

IPSec was not designed for failover situations and we recommend that you do NOT use IPSec for applications in a Server cluster.

Grund für diese Empfehlung ist die Art und Weise, wie die Sicherheitszuordnungen (SAs) des IPSec Internet Key Exchange (IKE) gespeichert werden – nämlich in einer lokalen und damit Nodes-pezifischen Datenbank.

Bei einem Failover müssen daher alle IPSec Verbindungen neu initiiert werden, um eine neue IKE SA auszuhandeln. Dieser Prozess dauert bei einem Windows 2000 Server Cluster per default 6 Minuten: 5 Minuten für den IPSec Idle Timeout, 1 Minute für das Re-initiieren durch den IKE (siehe » KB306677).
Das erhöht die Failoverzeit beträchtlich und senkt die potentielle Uptime…

Auf einem Windows Server 2003 Cluster kann diese Zeit per Registry immerhin auf 2 Minuten gedrückt werden, daher hat sich die ursprüngliche Empfehlung von Microsoft inzwischen wieder etwas relativiert.
Im Falle von Exchange 2003 ist ein Cluster Setup im Zusammenhang mit IPSec auch supported:

» How to Configure IPSec on an Exchange … Cluster

Mit der Hilfe des Registry-Keys NLBSFlags=1 kann in einer Multi-Tier Umgebung mit zB. NLB Frontendserver die IPSec idle time von 5 auf eine Minute gesenkt werden. Zusammen mit der IKE Re-initiierung (+1 Minute) kommt man dann auf die erwähnten 2 Minuten. Der Key ist in folgendem Zweig zu finden:
HKLM\SYSTEM\CurrentControlSet\Services
    \PolicyAgentOakley

Alles in allem muss abgewägt werden, ob man mit der zusätzlichen Verzögerung bei einem Failover leben kann bzw. ob dies die jeweiligen SLAs erlauben.

Für Windows Server 2008 Cluster hat sich das geändert, in Verbindung mit Windows Vista ist IPSec nicht mehr abhängig von Timeouts und kann bei einem Failover sofort eine neue SA aushandeln.

Stay tuned,
N.Own

Windows Server 2003 Cluster ohne NetBIOS?

Im Prinzip benötigt ein reiner Windows Server 2003 Cluster keine NetBIOS Funktionalität mehr, allerdings gängige Applikationen, die ein Cluster bereitstellt – daher ist die Frage mit einem klaren „Jein“ zu beantworten.
Technisch ist es machbar, mit gewissen Einschränkungen:

» TechNet: NetBIOS in Cluster Networking

Zudem kann folgender Fehler bei der Namensauflösung vorkommen:

\\<FQDN>
You were not connected because a duplicate name exists on the network. Go to System in Control Panel to change the computer name and try again.

Dieser kann über den Registry Eintrag DisableStrictNameChecking gelöst werden, mehr dazu unter folgendem KB Artikel (KB914056):
» You may receive error messages if you disable NetBIOS…

Auch wenn es technisch machbar ist für den reinen Cluster Betrieb, so kommt doch nicht jede Applikation damit zurecht – so zum Beispiel Exchange:
» Exchange Server 2003 require NetBIOS name resolution…

Zu dem Thema NetBIOS und speziell Exchange hat MVP Kollege Russ Kaufmann einen Blog Artikel verfasst:
» Russ Kaufmann: WINS is a Friend of Mine

Fazit: In einem LAN, in dem man Applikationen wie Exchange 2003 sowie Windows XP clients inkl. third party software etc. findet, sollte man lieber ein, zwei WINS Server bereithalten. Diese schränken die unangenehmen NetBIOS Broadcasts ein und stellen sicher, daß auch legacy Apps noch laufen.

Wer sich im Detail für die Namensauflösung und deren Wege in einem LAN interessiert, findet in diesem TechNet Artikel detaillierte Informationen nebst passender Schaubilder zum Thema Name Resolution aus dem Windows XP Professional Resource Kit:
» Configuring IP Addressing and Name Resolution

Stay tuned,
N.Own

Hyper-V goes RTM

Windows Server Hyper-V ist seit kurzem als RTM Version verfügbar (Build 6.0.6001.18016) und damit offiziell gelaunched:

» http://www.microsoft.com/hyper-v

Interessanterweise läuft die Microsoft Website bereits seit Anfang Juni komplett unter Hyper-V – natürlich auf einem Windows Server Cluster 😉
Interessante Daten und Zahlen sowie Uptime charts gibt es im Windows Server Division Weblog:
» Microsoft.com Powered by Hyper-V

Zum Download: » Holt Euch das update zur RTM

Stay tuned,
N.Own

W2K3 SP2: Resource Monitor may crash…

Gestern erreichte mich eine Mail mit der Information, daß der Resource Monitor bei einem Windows Server 2003 Cluster mit SP2 sporadisch abstürzen könnte. Der Crash tritt nur mit installiertem SP2 oder Hotfix 921181 (File Share Witness) auf.

Es gibt für diesen Fall einen Hotfix:
» http://support.microsoft.com/kb/948701/en-us
Der Hotfix kann direkt per Weblink angefordert werden:
» http://support.microsoft.com/hotfix/KBHotfix…

Eine Suche nach der Crashdump Datei des Resource Monitor (resrcmon.dmp) im %SYSTEMROOT%\Cluster gibt Aufschluss über einen vorhergehenden Absturz.
Der passende Eintrag im cluster.log ist in o.g. KB Artikel aufgeführt. Der gefixte resrcmon.exe trägt die Version 5.2.3790.4250

Stay tuned,
N.Own

Cluster Shares per Batchdatei anlegen

Wer auf mehreren Clustern Freigaben für Home-, Profil- und Ablagelaufwerk anlegen muss, kann dies auch über Batchdatei erledigen.
Hier ein Beispiel:

REM Freigaben für Standort im Cluster anlegen
REM
REM %1 = Virtueller Name des Clusters (Clustergruppe), %2 = Standortinfo 1 , %3 = Standortinfo 2, %4=File Server Clustergruppe
REM Sample: ‚cluShares.bat CLU01MUC015N Aussenstelle Musterstadt CLU01MUC020N‘
REM Just change the pathvar and everyone variable to your File Share and Everyone identifier
REM v 0.5, 04.08.07 – n.own @ mvps.org

REM @echo off
SET pathvar=F:\Kunde
SET everyone=Jeder
SET diskres=Disk F:

IF EXIST „%pathvar%\%2“ goto Process

:Process
cluster %1 res „Freigabe Home %2 %3″ /create /group:“%4″ /type:“File Share“
cluster %1 res „Freigabe Home %2 %3″ /priv path=“%pathvar%\%2\Home %2 %3“
cluster %1 res „Freigabe Home %2 %3″ /priv Sharename=“Home %2 %3“
cluster %1 res „Freigabe Home %2 %3″ /priv Remark=“Freigabe für %2 %3“
cluster %1 res „Freigabe Home %2 %3″ /prop Description=“Freigabe für %2 %3“
cluster %1 res „Freigabe Home %2 %3“ /priv security=%everyone%,grant,f:security
cluster %1 res „Freigabe Home %2 %3“ /priv ShareSubDirs=0
cluster %1 res „Freigabe Home %2 %3″ /AddDep:“%diskres%“
cluster %1 res „Freigabe Home %2 %3″ /AddDep:“%4 Name“
REM cluster %1 res „Freigabe Home %2 %3“ /on

cluster %1 res „Freigabe Profiles %2 %3″ /create /group:“%4″ /type:“File Share“
cluster %1 res „Freigabe Profiles %2 %3″ /priv path=“%pathvar%\%2\Profiles %2 %3“
cluster %1 res „Freigabe Profiles %2 %3″ /priv Sharename=“Profiles %2 %3“
cluster %1 res „Freigabe Profiles %2 %3″ /priv Remark=“Freigabe für %2 %3“
cluster %1 res „Freigabe Profiles %2 %3″ /prop Description=“Freigabe für %2 %3“
cluster %1 res „Freigabe Profiles Profiles Memmingen“ /priv security=%everyone%,grant,f:security
cluster %1 res „Freigabe Profiles %2 %3“ /priv ShareSubDirs=0
cluster %1 res „Freigabe Profiles %2 %3″ /AddDep:“%diskres%“
cluster %1 res „Freigabe Profiles %2 %3″ /AddDep:“%4 Name“
REM cluster %1 res „Freigabe Profiles %2 %3“ /on

:END
echo End of batch

Das Script muss noch vor der Nutzung an die eigene Umgebung angepasst werden, unter pathvar gehört der lokale Pfad der Daten, der Everyone identifier lautet je nach OS Sprache ‚Jeder‘ oder ‚Everyone‘. ‚Disk F:‘ steht stellvertretend für die Bezeichnung der Physical Disk Resource.

Das script kann leicht durch Hinzufügen des jeweiligen cluster.exe blocks zum Anlegen weiterer Freigaben erweitert werden. Zur Automatisierung und Einhaltung einer Konformität finde ich das Script sehr praktisch.

Das Batchfile steht hier auch zum Download bereit:
cluShares.bat

Stay tuned,
N.Own