Windows .NET Server RC1

Die Serverversion von Windows XP, inzwischen als .NET Server bezeichnet, wird noch etwas auf sich warten lassen. Ein Grund ist die von Bill Gates verordnete Zwangspause, in der der komplette Code auf potenzielle Sicherheitslücken überprüft wurde. Inzwischen hat der .NET-Server, der die Serverversionen von Windows 2000 ablösen soll, immerhin den Status Release Candidate 1 erreicht. In der englischen Version ist dieser auch wieder als Customer Preview Program erhältlich, um potenziellen Kunden einen Vorgeschmack zu geben.

Zum Testen stand uns die Build 3663 der Enterprise-Version zur Verfügung, die wir auf einer Dell Workstation 530 MT mit zwei Xeon 2,2-GHz-CPUs und 1024 MByte RAM installiert haben. Dabei haben wir weniger Augenmerk auf die Geschwindigkeit des RC1 gelegt, sondern vor allem die Sicherheit und insbesondere die neuen Features, die das .NET im Produktnamen rechtfertigen sollen, ins Visier genommen.

Versionen und Fähigkeiten

Windows .NET wird in vier verschiedenen Versionen erscheinen:

Der .NET Web Server ist ein speziell auf Web-Hosting angepasstes und optimiertes Produkt. Er kann mit maximal zwei Prozessoren und zwei GByte RAM ausgestattet werden und enthält unter anderem den IIS 6.0, das .NET Framework, Network Load Balancing, IPv6 sowie das Distributed File System und das Encrypted File System (DFS, EFS). Er kann zwar in eine Domäne eingebunden werden, jedoch nicht als Domänen-Controller agieren.

Der .NET Standard Server soll in kleinen und mittleren Unternehmen zum Einsatz kommen. Gegenüber dem Web Server unterstützt er bis zu vier GByte RAM und enthält zusätzlich unter anderem den Zertifikatsdienst, Public Key Infrastructure, Internet Authentication Services, Terminaldienste sowie die Windows Media Services.

Mit dem .NET Enterprise Server lassen sich bis zu acht Prozessoren und bis zu 32 GByte RAM adressieren. Zudem können bis zu acht Server in einem Cluster zusammengefasst werden. In der 64-Bit-Version sollen bis zu 64 GByte RAM möglich sein.

Das Flaggschiff ist der .NET Datacenter Server. Hier sind die Kenndaten bis zu 32 Prozessoren, maximal 64 GByte RAM sowie ebenfalls Cluster-Fähigkeiten für bis zu acht Server. Die 64-Bit-Variante soll bis zu 256 GByte RAM verwalten können.

Das .NET-Framework wird auf den 64-Bit-Versionen nicht unterstützt.

Versionen im Überblick

Die wichtigsten Funktionen im Überblick

Feature	Web	Standard	Enterprise	Datacenter
Angaben hinter dem Schrägstrich bei Enterprise und Datacenter beziehen sich auf die 64-Bit-Variante.
Max. CPUs	2	2	8	32
Max. RAM	2 GByte	4 GByte	32/64 GByte	64/256 GByte
.NET Framework	ja	ja	ja/nein	ja/nein
IIS 6.0	ja	ja	ja	ja
ASP.NET	ja	ja	ja	ja
Enterprise UDDI	nein	ja	ja	ja
Network Load Balancing	ja	ja	ja	ja
Clustering	nein	nein	8 Server	8 Server
VPN	1 Connection/Medium	ja	ja	ja
IAS	nein	ja	ja	ja
IPv6	ja	ja	ja	ja
Active Directory	nur als Mitglied	ja	ja	ja
Meta Directory	nein	nein	ja	ja
DFS	ja	ja	ja	ja
EFS	ja	ja	ja	ja
Shadow Copy	ja	ja	ja	ja
Removable und Remote Storage	nein	ja	ja	ja
Fax Service	nein	ja	ja	ja
Macintosh Services	nein	ja	ja	ja
IntelliMirror	ja	ja	ja	ja
Resultant Set of Policy	ja	ja	ja	ja
WMI Kommando-zeile	ja	ja	ja	ja
Remote OS Installation	ja	ja	ja	ja
Remote Installation Services	nein	ja	ja	ja
Windows Media Services	nein	ja	ja	ja
Internet Connection Firewall	nein	ja	ja	nein
PKI, Certificate Services, Smart Cards	nur als Client	ja	ja	ja
Remote Desktop	ja	ja	ja	ja
Terminal Server	nein	ja	ja	ja

Sicherheitsmaßnahmen

Die Weiterentwicklung des .NET-Server musste im Frühjahr dieses Jahres wegen der Sicherheitsinitiative von Microsoft zurückgestellt werden. Statt neue Features einzubauen, ließ Chef-Software-Architekt Bill Gates jede Zeile Code auf Bugs, Sicherheitslücken und potenzielle Sicherheitsrisiken überprüfen. Anstatt der veranschlagten vier Wochen benötigten Entwickler und externe Firmen dafür ganze zwei Monate, inklusive entsprechender Schulungen für die 8500 beteiligten Programmierer. Jede einzelne Datei musste "unterschrieben" werden, so dass eine Verantwortlichkeit für später auftretende Sicherheitslücken hergestellt werden kann. Aber nicht nur das Betriebssystem selbst, sondern auch ActiveX-Controls und sogar Beispielcodes, die in SDKs und DDKs mitgeliefert werden, hat man einer gründlichen Überprüfung unterzogen.

Dementsprechend gilt jetzt bei Microsoft die Devise "Secure out of the box". Das bedeutet unter anderem, dass per Default kein Netzwerkdienst wie etwa der IIS 6.0 installiert oder gestartet ist.

Auch bei nachträglicher Installation des IIS sind zunächst nur grundlegende Funktionen aktiviert. Zudem hat das Entwicklerteam einer ganzen Reihe von Diensten die Rechte entzogen. So laufen jetzt deutlich weniger Services als LocalSystem. Jeder Dienst soll nur so viele Rechte bekommen wie nötig, damit selbst bei Vorhandensein einer noch unentdeckten Sicherheitslücke der Schaden minimiert wird.

IIS 6.0 und ASP.NET

Die neue Version 6.0 des Internet Information Server stellt einen Kernbestandteil der .NET-Features dar. Allerdings war der Webserver in früheren Versionen massiv in Verruf geraten, weil er in den Augen vieler ein eklatantes Sicherheitsrisiko darstellt. Nicht zu Unrecht, wie Nimda und Konsorten gezeigt haben. In der Version 6 soll der IIS endlich sicher sein, verspricht die Entwicklungsabteilung aus Redmond.

Das erste Sicherheits-Feature ist, dass der IIS nicht per Default installiert wird. Bei nachträglicher Installation liefert er zunächst nur statische HTML-Seiten aus. Dynamischer Content via SSI, ASP oder ASP.NET muss separat eingerichtet und eingeschaltet werden.

Über einen so genannten Worker Process (w3wp.exe) werden dynamische Inhalte ausgegliedert. Dieser Prozess lässt sich mehrfach starten, um beispielsweise eine bessere Skalierung auf SMP-Systemen zu erreichen und die einzelnen Applikationen voneinander abzuschotten. Hängt sich eine auf, so sind andere davon nicht betroffen. Ein weiteres wichtiges Feature von ASP.NET 1.1 ist, dass es weitere Instanzen des Worker Process starten kann. Das kann man auch so konfigurieren, dass zum Beispiel nach einer bestimmten Zeit oder einer konfigurierten Anzahl bedienter Anfragen quasi ein "Recycling" erfolgt. Damit wird verhindert, dass eine schlecht programmierte Anwendung so nach und nach Speicher in einem schwarzen Loch verschwinden lässt.

Ebenfalls neu ist, dass die Konfiguration des IIS nicht mehr im Binärformat abgelegt wird, sondern in einer XML-Datei. Damit ist die Konfiguration mittels eines Texteditors einfach zu verändern oder per Dateikopie auf einen anderen Rechner zu übertragen.

Einen deutlichen Performance-Schub soll die Verlagerung einiger Bestandteile des IIS in den Kernel-Mode des Betriebssystems bringen (http.sys). Ein Teil der Verarbeitung wie Antwort-Queue, Namespace Mapper oder Cache lagern hier. Kann eine Anfrage komplett aus dem Cache bedient werden, entfällt der Zeit raubende Kontextwechsel von Kernel-Mode nach User-Mode.

Dateisystem DFS, EFS, Volume Shadow Copy

Obwohl Windows schon seit Windows for Workgroups Dateifreigaben erlaubt, hat sich bis zum .NET-Server eine ganze Menge weiter entwickelt, angefangen von NTFS mit seiner erweiterten Rechteverwaltung, das mit Windows NT eingeführt wurde, über die Features Kontingentverwaltung, Encrypted Filesystem (EFS) und Verteiltes Dateisystem (DFS) bei Windows 2000 bis hin zur so genannten Volume Shadow Copy im .NET-Server.

Dieser Dienst stellt ein neues temporäres oder permanentes Volume bereit, das ein Abbild eines anderen existierenden Volumes zu einer bestimmten Zeit darstellt.

"Copy-on-Write" bedeutet, dass die Kopie nicht sofort angelegt wird und damit gleich den Speicherplatz verbraucht, sondern erst, wenn eine Datei tatsächlich verändert wird. Eine Volumenschattenkopie von einem vier GByte großen Volume ist also zunächst einmal leer. Ein kleiner Nachteil bei dieser Lösung ist, dass der Zeitpunkt, an dem die Schattenkopie angelegt wird, vom Administrator bestimmt ist. Wünschenswert wäre ein Feature, bei dem immer automatisch die letzten n Versionen eines Dokuments gesichert werden.

Beim DFS hat Microsoft ebenfalls einige Verbesserungen anbringen können. Bei DFS lassen sich mehrere Verzeichnisse - auch auf verschiedenen Servern - zu einer einzigen Freigabe zusammenfassen. Handelt es sich dabei um Replikas, ist .NET nun in der Lage, den User zum kostenmäßig günstigsten Server zu leiten.

Active Directory

Die erste Version von Directory Services bietet immer viel Raum für Verbesserungen. So musste es Novell mit seiner NDS seinerzeit erleben, und so ging es auch Microsoft mit der Einführung des Active Directory in Windows 2000. Eine Reihe von Nebeneffekten hatte man in Redmond nicht bedacht, daher hagelte es Beschwerden von AD-Nutzern.

Ein Kritikpunkt war beispielsweise, dass nicht ständig mit der Zentrale verbundene Zweigstellen zwingend einen eigenen Global Catalog Server benötigen, der eine zusätzliche Replikation erforderlich macht und unnötig Festplatten- und Hauptspeicher verbraucht. Dies liegt daran, dass ein Domänen-Controller beim Logon den GC-Server kontaktiert, um mögliche Mitgliedschaften in einer universellen Gruppe aufzulösen. Und wenn ein GC nicht erreichbar ist, schlägt der komplette Logon-Vorgang fehl. Im .NET-Server kann der Domänen-Controller die komplette Mitgliedschaft von Benutzern cachen und somit ohne Zugriff auf den GC auskommen. Somit entfällt die Notwendigkeit für einen GC in der Zweigstelle.

Beim Einrichten von zusätzlichen Domänen-Controllern, etwa für Zweigstellen, dauert unter Windows 2000 allein das Replizieren des Active Directory unter Umständen Stunden oder gar Tage. Mit Windows .NET kann ein Administrator jetzt die initiale Replikation auch aus einer Backup-Datei heraus durchführen. Die seit dem Backup erfolgten Änderungen am AD werden dann durch eine normale Replikation über das Netzwerk eingespielt.

AD und Replikation

Ein besonders schwerer Kritikpunkt bei AD unter Windows 2000 sind die so genannten "multi-valued attributes", wie sie etwa für Gruppenmitgliedschaften verwendet werden. Ändert sich nur ein Wert in einem solchen Attribut, wird das gesamte Datenfeld neu repliziert. Erweitert der Administrator beispielsweise eine Gruppe mit 5000 Mitgliedern um ein Mitglied, muss dennoch die ganze Liste repliziert werden, was Bandbreite, Rechenzeit und Hauptspeicher unnötig belastet. Deshalb sind unter Windows 2000 Gruppen mit maximal 5000 Mitgliedern möglich, so dass man bei einem größeren Bedarf mehrere Gruppen managen muss. In einer Umgebung mit mehreren Master-Replikas kann es sogar dazu führen, dass Änderungen bei der Konfliktlösung verworfen werden. Unter .NET entfallen diese Probleme, allerdings nur in einer reinen .NET-Umgebung.

Bei der Replikation bietet sich der automatische Inter-site Topology Generator (ISTG) an, der den optimalen Replizierungsweg berechnet. Unter Windows 2000 schlägt das Tool jedoch fehl, sobald mehr als 200 Sites beteiligt sind. Der Grund: ISTG unter Windows 2000 verwendet einen "Least-cost spanning-tree"-Algorithmus, der eine Komplexität von O(d*s*s) aufweist. Normalerweise läuft der ISTG alle 15 Minuten, doch bei mehr als 200 Sites dauert allein die Berechnung des Baums länger. Bei Windows 2000 gilt es also, die Verbindungen zwischen den Sites manuell zu konfigurieren. Für .NET hat Microsoft den Algorithmus deutlich verbessert, so dass er jetzt nur noch eine lineare Komplexität O(d*s) aufweist. Auch hier gilt allerdings, dass es nur in einem rein aus .NET-DCs bestehenden Netz funktioniert, da alle DCs zum selben Topologie-Ergebnis kommen müssen.

Ein echtes Ärgernis bei AD ist, dass ein Domain-Name unveränderlich ist, sobald er einmal vergeben wurde. Zum einen sind viele Administratoren zu voreilig bei der Vergabe, oder Chefs haben plötzlich andere Wünsche, und zum anderen werden Namensänderungen spätestens bei einer Firmenübernahme ohnehin erforderlich. In einer nur aus .NET-Servern bestehenden Umgebung ist das jetzt endlich möglich.

Weitere Verbesserungen finden sich im MMC-Snapin zur AD-Verwaltung, das jetzt Drag-and-Drop sowie die gleichzeitige Bearbeitung von Attributen an mehreren Objekten unterstützt.

Fazit

Die neue Serverfamilie wartet mit vielen Verbesserungen im Detail auf. Insbesondere bei der Verwaltung hat sich einiges getan. Ein bei Microsoft häufig auftretendes Phänomen: In einer Version werden neue Features eingeführt, aber erst eine Version später sind sie auch so integriert, dass sie nutzbar sind, ohne sich bei der Einrichtung oder Verwaltung zu verbiegen.

Inwieweit die Sicherheitsinitiative einen Fortschritt gebracht hat, wird sich erst zeigen, sobald eine entsprechende Anzahl an .NET-Servern im und am Netz hängt.

Welche Neuigkeiten .NET im Bereich Netzwerk-Connectivity zu bieten hat, zeigen wir in einem späteren Artikel. Vergleichende Performance und Stabilitätsmessungen machen wir dann am finalen Produkt, dessen Fertigstellung für das Ende dieses Jahres erwartet wird. (mha)

tecCHANNEL Buch-Shop

Literatur zum Thema Windows	Bestell-Link
Titel von Pearson Education	Bestellung

Testkonfiguration

Komponente	Daten
Computer	Dell Workstation 530 MT
CPU	2x Intel Xeon 2,2 GHz, 512 kByte L2-Cache
Chipset	Intel i860
Mainboard-Version	A00
BIOS-Version	A05
Speicher	4x 256 MByte PC800-RDRAM mit ECC
Grafikkarte	NVIDIA Quadro2 EX, 32 MByte
Controller	Dell PERC3 SCSI RAID, 64 MByte Cache
Festplatten	2x Fujitsu MAM3184MP, 18,4 GByte, 1500 rpm, Ultra 160, im RAID-0-Verband
Netzwerk	3Com 3C920v3 Fast EtherLink XL 10/100 PCI
CD-ROM	LG CDR-8482B
DVD-Brenner	Philips DVD+RW-D01
Sound	AC'97 Vollduplex-Audio integriert
Sonstiges	2x Firewire- (IEEE1394) Schnittstelle
Betriebssystem	Windows .NET Enterprise Server