Windows.Net Server ...der Nachfolger für die Windows 2000 Serverfamilie

Cerberus
Windows.Net Server ...der Nachfolger für die Windows 2000 Serverfamilie



1. Was ist denn nun eigentlich neu ?:

Während der Client der neuen Windows-Version unter der Bezeichnung Windows XP bereits auf dem Markt ist, wird die Serverversion (Codename "Whistler") wohl nicht vor dem Winter 2002 als Windows.Net Server ausgeliefert werden. An dem zeitlichen Abstand zwischen der Client- und der Servervariante ebenso wie an den unterschiedlichen Bezeichnungen wird deutlich, dass Microsoft seine Entwicklungslinien nun nicht mehr in Windows 9x und Windows NT/2000/XP trennt, sondern in Clients und Server.

Der Windows.Net Server wird dementsprechend schon wieder einige Verbesserungen aufweisen, die bei Windows XP noch nicht zu finden sind. Das beginnt bei einer erweiterten Funktionalität von WMI (Windows Management Instrumentation) und geht bis zur neuen Version 6.0 der Internetinformationsdienste statt der bei Windows XP integrierten Version 5.1. Auch für den Betrieb im Netzwerk gibt es keine direkten Abhängigkeiten zwischen den beiden Entwicklungslinien. Die Funktionen von Windows XP lassen sich denn auch voll mit einem Windows-2000-Server nutzen.

Der Fokus bei der Entwicklung von Windows.Net Server liegt dagegen auf neuen, eigenständigen Serverfunktionen. Dazu gehören zusätzliche Dienste wie die Integration des Microsoft SharePoint Portals, neue Sicherheitsfeatures, aber eben auch Verbesserungen für das Clientmanagement.

Wichtige Detailverbesserungen

Das zentralisierte Management von Clients steht bei Microsoft seit dem Beginn der Diskussion über TCO (Total Cost of Ownership) vor rund fünf Jahren ganz oben auf der Prioritätenliste. Mit Windows 2000 und den dort eingeführten Funktionen für das Änderungs- und Konfigurationsmanagement (Change and Configuration Management), wie beispielsweise den Remote Installation Services (RIS), der Synchronisation von Offline-Dateien und insbesondere den Gruppenrichtlinien für eine differenzierte Steuerung von Clients, wurde hier ein erster Meilenstein erreicht. Beim Windows.Net Server sind es nun eher kleine, aber wichtige Verbesserungen, die umgesetzt wurden.

Einige der erweiterten Features finden sich auch schon bei Windows XP. Dazu gehört das Werkzeug RSoP (Resultant Set of Policies), mit dem die Abhängigkeiten zwischen verschiedenen Gruppenrichtlinien einfacher analysiert werden können. Zu nennen sind hier aber insbesondere auch die automatischen Updates und die Remote Assistance. Diese Funktionen finden sich auch beim Windows.Net Server. Neben diesen clientseitigen Funktionen - bei der Remote Assistance verhält sich ein Windows.Net Server nicht anders als ein Windows-XP-System - gibt es aber auch viele Verbesserungen bei der Serverfunktionalität beziehungsweise Optimierungen, die nur im Zusammenspiel mit Windows.Net Servern voll zum Tragen kommen.

Leistungsfähigere Gruppenrichtlinien

Die Gruppenrichtlinien sind gleichermassen komplex wie leistungsfähig. Mit ihrer Hilfe lassen sich Regeln für die Systemkonfiguration und Sicherheitseinstellungen treffen, die dann auf Clients und Server in der Domäne übernommen werden. Da auch noch zusätzliche Parameter mit Hilfe eigener Richtlinienvorlagen aufgenommen werden können, lässt sich die Clientadministration damit in weiten Teilen automatisieren.

Beim Windows.Net Server kommen nach dem aktuellen Stand noch einmal rund 170 Parameter in den Gruppenrichtlinien hinzu. Diese beziehen sich auf Bereiche wie die Systemsteuerung, die Information über Fehler, die Remote Assistance, DNS oder Roaming Profiles.

Für das Management von Gruppenrichtlinien ist insbesondere das RSoP (Resultant Set of Policies) interessant. RSoP wird als MMC-Snap-In bereitgestellt, das allerdings nicht standardmässig als Anwendung in der Gruppe Verwaltung eingerichtet wird. Das RSoP unterstützt zwei Modi:

• Im Planungsmodus erfolgt eine Analyse unter der Fragestellung, was bei der Durchführung von bestimmten Änderungen geschehen würde. Damit lassen sich die Auswirkungen von geplanten Anpassungen der Gruppenrichtlinien simulieren.

• Im Protokollierungsmodus werden dagegen Berichte zu den bestehenden Richtlinien für Benutzer und Computer erzeugt. Das RSoP ist insbesondere für komplexe Active-Directory-Strukturen ein wichtiges Werkzeug, um die Abhängigkeiten zwischen verschiedenen Gruppenrichtlinien auf Site-, Domänen- und OU-Ebene erkennen und beherrschen zu können.

Die vielleicht interessanteste Neuerung ist aber die Filterung über WMI-Informationen. WMI, die Windows Management Instrumentation, sammelt Angaben zur Konfiguration von Windows-2000-, Windows-XP- und Windows.Net-Server-Systemen und speichert diese in einer lokalen Datenbank. Diese Daten werden beispielsweise für die Anzeige von Systeminformationen in der Computerverwaltung verwendet. Beim Windows.Net Server können aber auch Filter für die Zuweisung von Gruppenrichtlinien definiert werden. Damit kann die Steuerung nicht mehr nur über Zugriffsberechtigungen, sondern auch anhand der Hard- und Software des Zielsystems erfolgen. Die Konfiguration erfolgt über die Eigenschaften der Gruppenrichtlinie und dort das Register WMI-Filter. Die Filter werden in Form von scriptbasierenden Abfragen erzeugt.

Vereinfachte Systeminstallation

Neben den schon im dritten Teil der Serie erläuterten Erweiterungen für die automatisierte Installation von Windows XP beispielsweise durch die Verbesserungen beim Setup-Manager hat Microsoft auch die Remote Installation Services (RIS) optimiert.

Diese profitieren einerseits von den Erweiterungen beim Setup-Manager, da dieser auch für die Erstellung von Antwortdateien für die RIS eingesetzt wird. Andererseits gibt es auch völlig neue Funktionen. So wird nun beispielsweise auch die Installation von Servern über RIS unterstützt, was gerade für Serverfarmen mit einer Vielzahl von Systemen eine interessante Option sein kann, aber auch für Unternehmen mit einer grösseren Zahl von Aussenstellen, für die Server vorbereitet werden müssen.

Erleichterte Softwareverteilung

Ein weiterer Bereich des Clientmanagements ist die Softwareverteilung. Auch hier gibt es eine Reihe von Optimierungen und neuen Funktionen. So kann bei Installationspaketen definiert werden, dass diese grundsätzlich vollständig eingerichtet werden. Das ist beispielsweise für mobile Benutzer wichtig, damit nicht bei der Verwendung der Anwendungen auf einmal Funktionen nicht zur Verfügung stehen, weil sie erst nachträglich installiert werden müssten. Durch die neuen 64-Bit-Versionen des Betriebssystems, bei denen 32-Bit-Anwendungen nur noch in einer Art Kompatibilitätsmodus unterstützt werden, wird auch eine zweite neue Option erforderlich. Es kann nun gezielt gesteuert werden, ob 32-Bit-Anwendungen für 64-Bit-Systeme bereitgestellt werden oder nicht.

Der für die Softwareverteilung genutzte Windows Installer kann nun mit digitalen Signaturen arbeiten. Somit lassen sich neu erstellte Softwareinstallationspakete nun auch signieren. Damit wird eine weitere Sicherheitsstufe geschaffen, weil so gesteuert werden kann, dass keine unautorisierten Pakete erstellt und gegebenenfalls im Netzwerk verteilt werden. Diese Regeln stehen in engem Zusammenhang mit neuen Sicherheitsrichtlinien, die als Softwareeinschränkung bezeichnet werden.

Dort kann beispielsweise konfiguriert werden, welche Herausgeber von Software überhaupt als vertrauenswürdig betrachtet werden. Diese Information wird aus den digitalen Signaturen von Softwareverteilungspaketen ermittelt. So lässt sich gezielt einschränken, welche Anwendungen auf einem System eingerichtet werden können.

Darüber hinaus wurde auch die Unterstützung für die Installation von Patches und die erneute Einrichtung von Anwendungen verbessert. Durch Hashs kann genauer überprüft werden, welche Dateien bereits vorhanden sind und welche noch nicht. Damit wird die Zahl der neu zu installierenden Dateien deutlich reduziert.

Konsequente Weiterentwicklung

Im Bereich des Clientmanagements wird der Windows.Net Server damit eher kleine, aber dennoch wichtige Verbesserungen bringen. Im Umgang mit Gruppenrichtlinien wird zwar auch weiterhin eine gute Planung erforderlich sein - die Auswirkungen lassen sich aber sehr viel leichter als bisher kontrollieren. Darüber hinaus gibt es auch eine beachtliche Zahl neuer Einstellungen in den Gruppenrichtlinien, so dass Clients noch besser als bisher über diese zentralen Richtlinien gesteuert werden können.

Microsoft setzt beim Änderungs- und Konfigurationsmanagement den mit Windows 2000 eingeschlagenen Weg auch bei Windows XP und beim Windows.Net Server konsequent fort. Deutlich wird auch, dass der Windows.Net Server eher eine Windows NT Version 5.1 - mit Windows 2000 als Version 5.0 - als eine Version 6.0 ist.

Das gilt auch für andere Bereiche wie die Sicherheit oder das Active Directory, auf die in den weiteren Folgen dieser Serie noch eingegangen wird. Dennoch wird schon in diesem Bereich deutlich, dass das Update auf den Windows.Net Server sehr viel zwingender sein wird als der Schritt von Windows 2000 Professional zu Windows XP Professional.


2. Neues Systemmangement:

Windows.Net Server bringt eine neue Version des Active Directory, das mit einer effizienteren Replikation und mehr Flexibilität funktional deutlich erweitert wurde.

Auch wenn Microsoft für das Active Directory keine Versionsangaben führt - mit dem Windows.Net Server wird der Verzeichnisdienst funktional deutlich erweitert. Der Fokus liegt auf effizienterer Replikation und mehr Flexibilität, aber auch auf besserer Kompatibilität mit anderen Systemen. Das gilt auch für die anderen Infrastrukturdienste wie DNS.

Das Active Directory hat sich schon in seiner ersten Version durch ein durchdachtes Konzept ausgezeichnet und bewährt. Das heisst aber noch lange nicht, dass es nicht noch vieles zu verbessern gibt, und insbesondere gab es auch Schwächen, die sich erst in der breiten praktischen Nutzung zeigten.

Hier sind vor allem drei Punkte zu nennen: Zum einen haben viele Unternehmen Probleme damit, dass Forests Strukturen sind, die kaum integriert werden können. Das betrifft auf der einen Seite Situationen, in denen Unternehmen zugekauft und bestehende Active-Directory-Infrastrukturen miteinander integriert werden. Es betrifft aber auf der anderen Seite auch Situationen, in denen beispielsweise durch Zuständigkeitskonflikte innerhalb der IT-Organisation oder das Fehlen einer solchen zentralen Organisation mehrere Forests in einem Netzwerk entstanden sind, die nun integriert werden sollen.

Der zweite Problembereich ist die Kompatibilität mit anderen LDAP-Verzeichnisdiensten. Hier gibt es eine permanente Entwicklung, an die ein Verzeichnisdienst angepasst werden muss - formal den Kern-RFCs zu folgen, reicht hier nicht.

Der dritte Aspekt ist schliesslich die Replikation. Das beim Active Directory gewählte Konzept ist hier zwar in den meisten Fällen effizient. Insbesondere in sehr grossen Netzwerken haben sich aber auch Schwächen gezeigt. So kann beispielsweise ab rund 100 Standorten eine Replikationstopologie nicht mehr automatisch erzeugt werden. Solche Aspekte werden nun beim Windows.Net Server adressiert.

Inter-Forest-Kommunikation

Das Active Directory arbeitet mit Forests, Domänen und organisatorischen Einheiten, um Netzwerke zu strukturieren. Die Domäne bildet dabei eine wichtige Struktur für Sicherheit und Administration. Berechtigungen vererben sich ebenso wie Gruppenrichtlinien und andere Einstellungen immer nur innerhalb einer Domäne, aber nicht über ihre Grenzen hinweg. Gleichzeitig definiert die Domäne die Partitionen für die Active-Directory-Replikation. Ein Forest wiederum ist insofern von Bedeutung, als bei Windows 2000 die transitiven Vertrauensstellungen nur innerhalb eines Forest erzeugt werden. Vertrauensstellungen mit anderen Forests können nur direkt zwischen zwei Domänen erstellt werden und sind nicht transitiv.

Das ändert sich beim Windows.Net Server. Dort lassen sich auch Trusts zwischen Forests konfigurieren. Diese müssen explizit eingerichtet werden. Dafür wird die Anwendung Active Directory-Domänen und -Vertrauensstellungen verwendet. Durch einen solchen Trust entstehen transitive Vertrauensstellungen zwischen allen Domänen in beiden Forests. Benutzer der Domäne netzwerk.beratung.test.com können also auf Ressourcen der Domäne vertrieb.beispiel.de zugreifen, auch wenn die domänenbäumetest.com und beispiel.de in zwei getrennten Forests erstellt worden sind.

Allerdings können keine transitiven Trusts über mehrere Forests hinweg erzeugt werden. Wenn es also die Forests test.com, beispiel.de und demo.ch gibt, dann müssen gegebenenfalls drei Forest-Trusts eingerichtet werden.

Forest-Trusts können darüber hinaus einseitig oder zweiseitig definiert werden. Damit kann beispielsweise erreicht werden, dass Administratoren einer Konzernzentrale die Forests von Konzerngesellschaften mit verwalten, ohne dass in die andere Richtung Zugriffe möglich sind.

Für die Anmeldung können sowohl NTLM als auch Kerberos verwendet werden. Kerberos, das bei Windows 2000, Windows XP und beim Windows.Net Server unterstützt wird, ist dabei die effizientere Lösung, da der Kommunikationsaufwand geringer ist.

Die Inter-Forest-Kommunikation gibt Administratoren neue Gestaltungsmöglichkeiten für die Active-Directory-Umgebungen. Das Design des Active Directory wird ebenso erleichtert wie Migrationsprozesse in grösseren Umgebungen mit einer verteilten IT-Administration. Für Unternehmen, die noch nicht auf das Active Directory umgestellt haben, macht es Sinn, diese neuen Optionen in ihre Strukturierungsüberlegungen einzubeziehen.

Erweiterte Replikationstechnologien

Auch wenn das Active Directory schon in seiner jetzigen Form durchaus effiziente Replikationsmechanismen aufweist, gibt es doch noch Verbesserungsmöglichkeiten und -bedarf. Gerade in sehr grossen Netzwerken gibt es einige Punkte, die zu einer relativ hohen Netzlast durch die Replikation führen können, auch wenn sie in kleineren und mittleren Umgebungen mit maximal wenigen tausend Benutzern kaum ins Gewicht fallen.

Ein Aspekt dabei ist die Berechnung der Inter-Site-Replikationstopologie. Beim Active Directory können und sollten Standorte konfiguriert werden, damit sowohl die Replikation des Active Directory als auch andere Dienste wie das DFS (Distributed File System) und der FRS (File Replication Service) WAN-Verbindungen so wenig wie möglich belasten. Das Active Directory berechnet dann über einen bei Windows 2000 als KCC (Knowledge Consistency Checker) bezeichneten Dienst die optimale Replikationstopologie für den Austausch von Active-Directory-Informationen zwischen verschiedenen Standorten. Dieser KCC hat aber den Nachteil, dass die Prozessor- und Speicheranforderungen der verwendeten Algorithmen exponentiell mit der Zahl der Sites steigen. Ab etwa 100 Standorten ist damit keine sinnvolle Berechnung der Replikationstopologie mehr möglich. Diese muss dann manuell konfiguriert werden.

Beim Windows.Net Server verwendet der nun als ISTG (Inter-Site Topology Generator) bezeichnete Dienst überarbeitete Algorithmen, die eine deutlich höhere Skalierbarkeit garantieren. Allerdings werden diese Algorithmen erst verwendet, wenn das komplette Netzwerk auf den Windows.Net Server umgestellt ist. Beim Windows.Net Server gibt es neben dem gemischten und dem einheitlichen Modus noch einen dritten Modus, in dem nur noch Windows.Net Server als Betriebssystem für Domänencontroller eingesetzt wird. Dieser wird derzeit zumeist als "Whistler Mode" bezeichnet, was sich aber noch ändern wird. In der vorliegenden Version kann die Umstellung nur über ntdsutil.exe erfolgen. Auch hier kann man davon ausgehen, dass es bis zur Final-Version noch Anpassungen geben wird.

Für viele Administratoren ist auch interessant, dass der Global Catalog in Domänen im einheitlichen Modus nicht mehr zwingend für die Anmeldung benötigt wird. Bisher musste an jedem Standort ein Global-Catalog-Server eingerichtet werden. Bei sehr grossen Netzwerken mit vielen kleinen Standorten mussten daher an jeden Standort Teilinformationen aller Domänen repliziert werden. Beim Windows.Net Server gibt es dagegen einen Cache für die Mitgliederlisten von universellen Gruppen. Dieser Cache kann auf Domänencontrollern explizit aktiviert werden. Die erforderlichen Informationen werden dann im Rahmen der normalen Replikationsprozesse an diesen Domänencontroller übertragen, so dass er immer auf dem aktuellen Stand ist und die vollständige Authentifizierung ohne Kontakt zu einem Global-Catalog-Server durchführen kann.

Optimiert wurde auch die Replikation von Gruppen. Bisher wird beim Hinzufügen oder Löschen von Mitgliedern in Gruppen die vollständige Liste aller Mitglieder an alle anderen Domänencontroller repliziert. Das führt bei grossen Gruppen mit vielen Mitgliedern zu einer erheblichen Replikationslast - man denke nur an eine Gruppe Domänen-Benutzer in einem Netzwerk, in dem einzelne Domänen schon mehrere tausend Mitglieder haben können. Beim Windows.Net Server werden im reinen "Whistler Mode" nur noch die Änderungen und nicht mehr die vollständigen Mitgliederlisten repliziert.

Reizvoll ist auch, dass bei der Einrichtung des Active Directory nun nicht mehr zwingend eine Vollinstallation erfolgen muss. Wenn dcpromo.exe, der Assistent für die Installation des Active Directory, im erweiterten Modus ausgeführt wird, können die Daten von einer Datensicherung gelesen werden. Diese werden dann im Rahmen der anschliessenden, regulären Replikationsprozesse aktualisiert. Das ist insbesondere für die Einrichtung von Domänencontrollern an entfernten Standorten und in grossen Netzwerken eine Erleichterung, weil bei einer Vollreplikation von grossen Active-Directory-Domänen unter Umständen sehr grosse Datenmengen übertragen werden müssen.

Die meisten Neuerungen bei der Replikation betreffen Details, haben aber dennoch für das Lastverhalten vor allem bei sehr grossen Netzwerken deutlich positive Auswirkungen.

Weitere Neuerungen beim Active Directory

Ebenfalls im Zusammenhang mit der Replikation steht eine weitere Neuerung. Das Active Directory unterstützt beim Windows.Net Server auch sogenannte Anwendungspartitionen. In diesen Partitionen können gezielt Daten von Anwendungen, die das Active Directory verwenden, gespeichert werden. Bisher werden diese Informationen, beispielsweise von einem Microsoft ISA Server oder einem Exchange Server, in den Domänen abgelegt.

Durch Verwendung der Anwendungspartitionen lassen sich die Objekte nun in einer gesonderten Partition speichern. Sie sind damit zum einen sauber getrennt. Zum anderen kann genau konfiguriert werden, auf welche Domänencontroller innerhalb eines Forest - nicht nur innerhalb einer Domäne - diese Informationen repliziert werden sollen.

Der Windows.Net Server wird diese Funktion beispielsweise für DHCP, RAS oder RADIUS unterstützen. Sie kann aber von Entwicklern auch für andere Anwendungen genutzt werden. Die einzige Einschränkung von Anwendungspartitionen ist, dass dort keine Security Principals, also für die Authentifizierung und Autorisierung verwendeten Objekte wie Benutzer, Gruppen und Computer, gespeichert werden können.

Wichtig ist auch, dass das Schema eines Forest weiterhin für die Anwendungen angepasst werden muss, auch wenn deren Informationen in einer gesonderten Anwendungspartition abgelegt werden.

Erweitert wurde auch die Kompatibilität mit anderen LDAP-Implementierungen. Eine wichtige Erweiterung ist dabei die Unterstützung der Klasse inetOrgPerson, die beispielsweise vom iPlanet Directory Server verwendet wird und mittlerweile auch im RFC 2798 definiert ist. Diese Klasse kann nun alternativ zur Klasse user eingesetzt werden. Damit lassen sich Informationen zwischen beispielsweise dem iPlanet Directory Server und dem Active Directory einfacher replizieren.

Unterstützt werden nun auch dynamische Einträge entsprechend dem RFC 2589, denen eine definierte Lebensdauer (TTL, Time to Live) zugewiesen ist. Auch TLS (Transport Layer Security) entsprechend dem RFC 2830, also der geschützte Zugriff auf das Active Directory, ist nun implementiert. Für die Rückgabe von grossen Ergebnislisten wird nun zudem der VLV (Virtual List View) unterstützt. Mit dem VLV kann ein Client Teile der Ergebnisliste anfordern, statt beispielsweise mehrere tausend gefundener Einträge geliefert zu bekommen.

Administratoren werden schliesslich die Speicherung von Abfragen schätzen. Damit können wiederkehrende Selektionen in einem Objekt im Active Directory abgelegt und jederzeit wieder aufgerufen werden.

DNS mit Sicherheitserweiterungen

Bei der DNS-Implementierung des Windows.Net Server wurde insbesondere die Vorgehensweise beim Hinzufügen von Domänen optimiert. Hier erfolgen nun umfassende Analysen, um sicherzustellen, dass neue Domänen korrekt zu DNS hinzugefügt werden können. Eine vergleichbare Unterstützung gibt es auch für das Hinzufügen neuer Computer zu einer Domäne. Falls es hier Probleme mit der DNS-Konfiguration gibt, wird explizit darauf hingewiesen.

Neu ist auch die grundlegende Unterstützung für die DNS-Sicherheitserweiterungen laut RFC 2535. Diese Erweiterungen erlauben es, dass ein DNS-Server auf Basis von Windows.Net Server als sekundärer Server für eine signierte DNS-Zone arbeiten kann. Allerdings kann er nicht als primärer Server für solche Zonen eingesetzt werden, da die Unterstützung des RFC nicht vollständig implementiert ist.

Interessant ist auch das bedingte Forwarding. Damit kann konfiguriert werden, welche DNS-Anfragen an welche DNS-Server weitergeleitet werden sollen. So können Anfragen nach .com an andere Server als solche nach .net geleitet werden. DNS-Strukturen lassen sich damit sehr viel flexibler als bisher gestalten.

Die grösste Bedeutung für Administratoren hat aber, dass DNS-Clients nun über Gruppenrichtlinien konfiguriert werden können. Damit lassen sich viele Einstellungen wie die zur dynamischen Registrierung einfach verwalten. Gleiches gilt auch für die Listen von unterstützten DNS-Suffixen, die auf Clients konfiguriert werden sollen.

DHCP und andere Dienste

Die wichtigste Erweiterung bei DHCP betrifft die Sicherung und Wiederherstellung. DHCP-Datenbanken können nun über eine grafische Oberfläche gesichert und wiederhergestellt werden. Die Sicherung kann auch im laufenden Betrieb erfolgen.

Bei anderen Diensten wie WINS oder dem RAS gibt es keine nennenswerten Erweiterungen. Aber schon die Anpassungen, die beim Active Directory vorgenommen wurden, lassen Vorfreude auf das Release des Windows.Net Server aufkommen, da sie einige zwar kleine Schwachstellen adressieren, die aber grosse Auswirkungen beispielsweise auf die Netzlast haben können.

3. Sicherheit und Netzwerk

Dass der Windows.Net Server mehr ein Upgrade als eine wirklich neue Betriebssystemversion ist, merkt man auch bei den Sicherheits- und Netzwerkfunktionen. Es gibt viele wichtige Neuerungen, aber die bahnbrechenden neuen Features fehlen. Doch vielleicht ist es gerade im Bereich der Sicherheit auch wichtig, erst einmal solide zu arbeiten, bevor viele neue Funktionen hinzukommen.

Es spricht aber sicher auch für den breiten Funktionsumfang, den schon der Windows 2000 Server hat, dass es mehr die Optimierungen als die Neuerungen sind, die beim .Net Server zu finden sind. Viele der Funktionen sind jedoch so attraktiv, dass sie einen schnellen Wechsel zum neuen Release des Windows-Server-Betriebssystems als überlegenswert erscheinen lassen.

Sorgenkind Sicherheit

Die Sicherheit ist das Sorgenkind von Microsoft. Auch wenn gerade die Analyse von Viren wie Nimda zeigt, dass sich Angriffe mit den zum Zeitpunkt des ersten Auftretens vorhandenen Patches hätten vermeiden lassen und dass ein erschreckend hoher Anteil der auftretenden Probleme durch Fehler in der Administration verursacht werden, gibt es doch auch noch etliche Schwächen beim Betriebssystem selbst. Neben den kontinuierlichen Security-Patches, die alle beim Windows.Net Server enthalten sein werden, gibt es aber auch noch andere Optimierungen.

So werden beispielsweise nun wesentlich grössere Log-Dateien als bisher unterstützt. Es lassen sich nun auch Dateien mit über 1 GB Grösse erzeugen und verwalten. In diese können neu Performance-Daten aufgenommen werden, so dass sie einen umfassenden Überblick über das Geschehen im System liefern. Die Log-Dateien verwenden ein neues Dateiformat. Das bisherige Format wird aber zur Abwärtskompatibilität weiter unterstützt.

Zu den vielen Erweiterungen der Gruppenrichtlinien gehört die Unterstützung von Netlogon-Parametern. Das Verhalten der Clients bei der Anmeldung lässt sich nun wesentlich differenzierter als bisher steuern. Das geht von der Steuerung der Registrierung von DNS-Einträgen über die Einstellungen zum Anmeldedialog bis hin zur Erkennung von Sites. Nicht alles davon ist direkt sicherheitsrelevant, wirkt sich dann aber zumindest auf die Netzwerkkommunikation und damit auch Netzlast aus.

Einerseits administrativen Charakter, andererseits aber auch Relevanz für die Sicherheit hat das Konzept der sogenannten Headless Server. Ein solcher Server verfügt weder über Grafikkarte noch über Tastatur oder Maus. Diese Systeme sind vor allem für Rechenzentren interessant, aber auch für weniger sichere Standorte. Sie können über die EMS (Emergency Management Services) auch nach Fehlern oder während des Startprozesses mit den Terminaldiensten, WMI oder Scripts verwaltet werden.

Für IPsec gibt es ein neues, grafisches Überwachungsprogramm. Mit diesem können gezielt die aktiven IPsec-Verbindungen überwacht werden. Es werden alle aktiven Verbindungen, aber auch die Konfigurationseinstellungen angezeigt.

Sicher kommuniziert werden kann aber nicht nur per IPsec. Gerade für die drahtlose Übertragung ist die Authentifizierung von Benutzern vor der Verwendung des LANs beispielsweise durch automatisch verteilte digitale Zertifikate von Bedeutung, da Wireless LANs derzeit unter dem Sicherheitsaspekt ja stark umstritten sind.

Die Zertifikatsdienste

Die Verteilung solcher Zertifikate wurde ebenfalls optimiert. Die Zertifikatsdienste des .Net Server können beispielsweise eine Autorisierung des Benutzers über eine Smartcard verlangen, bevor Zertifikatsanforderungen bearbeitet werden. Es kann aber auch definiert werden, dass mehrere Administratoren die Konfiguration der automatischen Verteilung von Zertifikaten bestätigen müssen, um sicherzustellen, dass nicht ein einzelner Administrator unbefugt Zertifikate ausgibt.

Wesentlich erweitert wurde auch die Unterstützung von CRLs (Certificate Revocation Lists). Mit Hilfe von CRLs werden Informationen über nicht mehr gültige Zertifikate für Anwendungen bereitgestellt. Beim .Net Server lassen sich mehrere CDPs (CRL Distribution Points) konfigurieren. Damit können die Anforderungen von Anwendungen verteilt oder CDPs verlagert werden, wenn das Netzwerk umkonfiguriert wird. Darüber hinaus wird ein Delta-CRL-Modell unterstützt: Anwendungen können damit die Änderungen in CRLs seit dem letzten Zugriff anfordern, statt jedes Mal die vollständige Liste zu laden.

Die Zertifikatsvorlagen, auf denen die erstellten digitalen Zertifikate basieren, können nun auch angepasst werden. Viele Zertifikate sollen in Unternehmen mit ganz bestimmten Vorgaben beispielsweise für die Authentifizierungsanforderungen von Anwendungen oder die Richtlinien für ihre Anwendung genutzt werden. Das lässt sich bei der Verwaltung der Vorlagen nun durchführen.

Für Administratoren ist aber wohl das Key Archival and Recovery, also die Sicherung und Wiederherstellung von Schlüsseln, die wichtigste Erweiterung. Private Schlüssel lassen sich mit Hilfe eines Recovery Agent wiederherstellen. Wenn Informationen verlorengegangen sind, lassen sich diese damit schnell und ohne Eingriffe von Benutzern wieder rekonstruieren. Dieser Dienst entspricht in seiner Funktionalität dem Exchange Key Management System (KMS) Server.

Erweiterte Netzwerkfunktionen

Auch bei den Netzwerkdiensten und -komponenten gibt es manche Neuerung. Das beginnt bei der Bridging-Funktionalität, mit der ein Server als Bridge zwischen zwei Segmenten mit unterschiedlichen Medien dienen kann. Darauf wurde bereits bei der Beschreibung von Windows XP im zweiten Teil der Serie eingegangen. Diese Änderung ist vor allem für sehr kleine Netzwerke relevant.

Für diese ist auch die automatische Feststellung der TCP Receive Window Size durch den lokalen Netzwerkadapter gedacht. Das TCP Receive Window definiert, wie viele Daten empfangen werden können, bevor eine Bestätigung gesendet wird. Der QoS Packet Scheduler auf einem System mit ICS (Internet Connection Sharing) ist damit nun in der Lage, die Fenstergrösse für die Kommunikation an die Geschwindigkeit der WAN-Verbindung anzupassen. Damit werden die Warteschlangen beim RAS-Server verkürzt, und neue Verbindungen lassen sich schneller aufbauen. Die Funktion steht nur im Zusammenspiel mit dem ICS zur Verfügung, beeinflusst die TCP/IP-Kommunikation sonst aber nicht.

Auch die TCP/IP-Unterstützung für den IEEE 1394 Serial Bus, eine Implementierung des RFC 2734, zielt eher auf kleinere Netzwerke ab. Damit können über solche Firewire-Connections Netzwerkverbindungen zwischen zwei Systemen aufgebaut und Informationen ausgetauscht werden. Die Funktion kann aber auch für mobile Nutzer interessant werden, die schnell und einfach zwei Notebooks miteinander verbinden möchten - dann allerdings eher über Windows XP als über den .Net Server.

Es gibt aber nicht nur Verbesserungen für den Einsatz des Systems in kleinen Netzwerken oder für Clients. So ist die TCP/UDP Port Ownership, die nun bei netstat.exe ausgegeben werden kann, vor allem für Netzwerkadministratoren und Sicherheitsverantwortliche interessant, da damit nachvollzogen werden kann, welcher Prozess einen Port geöffnet hat.

Sowohl im Bereich der Sicherheit als auch bei den Netzwerkfunktionen sind es kleine Schritte, die Microsoft beim .Net Server gemacht hat. Windows 2000 war das Release, das grundlegend neu entwickelt wurde - beim .Net Server wird nun optimiert. Dennoch hat es auch hier viele Funktionen, die einen mit Spannung auf das endgültige Release warten lassen. Was für den einen dann der Headless Server im Rechenzentrum ist, sind für den anderen die verbesserten Zertifikatsdienste. Der .Net Server ist damit nicht nur wegen der Erweiterungen beim Active Directory ein interessantes Upgrade zum Windows 2000 Server.

4. 64-Bit oder was ?

Mit dem Itanium-Prozessor wird das Thema der 64-Bit-Betriebssysteme auf der Intel-Plattform relevant. Und auch wenn derzeit eher noch Abwarten dominiert, so ist es doch letztlich nur eine Frage der Zeit, bis 64-Bit-Systeme und -Anwendungen sich auf breiter Front durchsetzen. Denn gerade die Grenze von 4 GB direkt adressierbarem Hauptspeicher, wie er in 32-Bit-Betriebssystemen existiert, wird im praktischen Einsatz zunehmend zum Engpass. Selbst bei Clients sind heute Hauptspeicher mit Grössen von 512 MB und darüber keine Ausnahme mehr.

Auf der Client-Seite ist der Schritt zum 64-Bit-Computing dabei schon vollzogen. Mit der Windows XP 64-Bit-Edition steht ein System bereit, das insbesondere auf High-End-Workstations im Grafik-Bereich ausgerichtet ist.

Auf der Server-Seite gibt es den Windows Advanced Server Limited Edition als Preview-Release der zukünftigen 64-Bit-Server-Plattform von Microsoft. Dieses System wird nur in Verbindung mit Itanium-basierender Hardware diverser Hersteller wie Dell, HP, IBM und Fujitsu angeboten.

Windows XP 64-Bit-Edition

Die Windows XP 64-Bit-Edition unterscheidet sich von Windows XP Professional vor allem in einem Punkt: Statt 4 GB RAM können im ersten Release bis zu 16 GB physischem Hauptspeicher und bis zu 8 Terabyte virtuellem Speicher genutzt werden. In zukünftigen Versionen soll dann, entsprechend der verfügbaren Hardware, auch mehr physischer Hauptspeicher genutzt werden können. Die Zielrichtung sind technische und grafische Workstations im High-End-Bereich, wo sich die Vorteile der 64-Bit-Systeme bei Fliesskommaoperationen und mit der unterstützten Menge an Hauptspeicher besonders deutlich auswirken.

Nicht zu unterschätzen sind daneben auch die Erweiterungen verschiedener Systemressourcen wie dem Paged Pool und dem Non-Paged Pool, deren Restriktionen sich heute insbesondere bei ressourcenintensiven Systemen bereits als Engpass auswirken.

Aus Sicht der Anwendungsentwicklung gibt es zwischen den 32-Bit- und den 64-Bit-Plattformen keine wesentlichen Unterschiede. Es werden im wesentlichen die gleichen API-Funktionen angeboten, wobei der verwendete Code dort, wo es Sinn macht, für die Nutzung der Itanium-Plattform optimiert wurde.

Im ersten Schritt ist die Windows XP 64-Bit-Edition eindeutig eine Plattform für die Einsatzbereiche, die heute bereits an die Grenzen der von Windows 2000/XP unterstützten Ressourcen stossen. Nur dort machen die aktuell noch hohen Investitionen in die benötigte Hardware Sinn. Aber wie schon eingangs gesagt: Es ist nur eine Frage der Zeit, bis sich das ändert und 64-Bit-Systeme auch auf breiterer Basis genutzt werden.

Advanced Server Limited Edition

Die 64-Bit-Variante des Windows Advanced Server wird von Microsoft explizit als Limited respektive Preview Edition bezeichnet. Das System wird nur mit geeigneter Hardware von OEMs ausgeliefert und ist für Early Adopters gedacht, die kurzfristig Bedarf für 64-Bit-Serverlösungen auf Basis von Windows haben. Das System wird nicht direkt an Endkunden vertrieben werden. Der Support erfolgt primär über die OEMs, wobei allerdings auch Microsoft den Release voll und nicht nur im Sinne einer Betaversion unterstützt.

Bei der Advanced Server Limited Edition handelt es sich nicht einfach um eine Servervariante von Windows XP 64-Bit-Edition, was sich schon an der Speicherunterstützung zeigt. Diese wird über 64 GB hinausgehen, wobei es noch keine eindeutigen Aussagen zum maximal unterstützten Hauptspeicher gibt. Der virtuelle Speicher kann bis zu 16 Terabyte gross werden.

Interessant sind auch die erweiterten Funktionen im Bereich des Hardware-Fehlermanagements. Mit diesem Feature, das auf einer Funktion des Itanium-Prozessors basiert, können Fehler bei Systemkomponenten gezielt erkannt werden, was die Verfügbarkeit von Serversystemen deutlich erhöhen kann.

Microsoft bezeichnet die Limited Edition als eine Windows.Net Server-Variante, die auf dem aktuellen Stand basiert und die bis zum Release des Windows.Net Server entsprechend erweitert wird.

Auf der anderen Seite gilt für die Limited Edition ebenso wie für die 64-Bit-Version von Windows XP, dass die 64-Bit-API weitestgehend der vertrauten 32-Bit-Windows-API entspricht. Die Umstellung von Anwendungen ist damit vergleichsweise einfach. Entsprechend arbeiten Anbieter von Anwendungssystemen wie SAP bereits intensiv an optimierten Lösungen. Microsoft selbst entwickelt eine 64-Bit-Version des SQL Server, die für Mitte 2002 angekündigt ist; die Portierung anderer .Net Server ist in der Planungsphase, konkrete Ankündigungen gibt es aber noch keine.

32-Bit-Anwendungen lassen sich unter dem 64-Bit-Windows in einem Subsystem ausführen. Da deren Performance auf 64-Bit-Prozessoren aber schlechter als auf 32-Bit-Plattformen ist, macht das nur in Ausnahmefällen Sinn. 16-Bit-Anwendungen schliesslich werden überhaupt nicht mehr unterstützt.

Ebenfalls für das 64-Bit-Windows weiterentwickelt wird der Microsoft Operations Manager (MOM), der die neue Plattform relativ frühzeitig unterstützen soll. Hier gibt es derzeit aber noch keinen konkreten Termin.

Ein detaillierter Blick

Dass die Limited Edition auf dem Windows.Net Server aufbaut, wird schon bei den Feature-Listen deutlich - aber auch, wenn man sich verschiedene Funktionen des Windows.Net Server betrachtet. So kann beispielsweise bei den Gruppenrichtlinien gezielt gesteuert werden, welche Anwendungen auch auf 64-Bit-Systemen eingerichtet werden sollen. Das ist schon deshalb wichtig, weil 64-Bit-Systeme auf Server- wie auf Client-Seite zunächst spezielle Einsatzbereiche haben werden und nicht alle Anwendungen darauf eingerichtet werden sollen. Hinzukommt die schwächere Performance der 32-Bit-Anwendungen auf diesen Systemen. Entsprechend wurde auch der Windows Installer erweitert, um 64-Bit-Komponenten korrekt verarbeiten zu können.

Die meisten der neuen Funktionen in der Limited Edition sind Funktionen, die sich in gleicher Weise auch beim bereits in den letzten drei Folgen der Serie besprochenen Windows.Net Server finden. Dazu zählen die automatisierte Systemwiederherstellung, die zusätzlichen Befehlszeilenwerkzeuge und natürlich auch die angepasste Oberfläche.

Auch die Erweiterungen beim Active Directory entsprechen in den meisten Bereichen denjenigen, die sich bei der aktuellen Betaversion des Windows.Net Server finden. Das Active Directory auf 64-Bit-Servern mit der Limited Edition ist mit anderen Active-Directory-Varianten interoperabel.

Umsteigen?

Wie schon beim Client, gilt auch beim Server: Ein Umstieg macht nur Sinn, wenn man die grössere Leistung des Systems auch wirklich benötigt. Gerade in Anbetracht dessen, dass die Limited Edition auf der Betaversion des Windows.Net Server basiert, will das gut überlegt sein. Zudem gibt es auch nur wenige verfügbare 64-Bit-Server-Anwendungen, die sich zum Grossteil auch noch in einem frühen Entwicklungsstadium befinden.

Richtig ernst wird es erst mit dem Release des Windows.Net Server, bei dem ziemlich zeitgleich auch die Final-Version des 64-Bit-Windows-Server auf den Markt kommen dürfte. Wer heute nicht zwingend darauf angewiesen ist, mit 64-Bit-Systemen zu arbeiten, sollte noch abwarten.

In vielen Fällen dürfte eine vergleichbare Skalierbarkeit auf ausgereifterer Soft- und Hardware zu erreichen sein, wenn man beispielsweise den Datacenter Server mit einer entsprechenden Zahl von Prozessoren einsetzt. Denn auch dort stehen immerhin bis zu 64 GB Hauptspeicher zur Verfügung. Und Lastverteilung lässt sich auch durch mehrere Instanzen von Anwendungen, die Verteilung auf mehrere Server und die Nutzung von SMP-Systemen erreichen. Selbstverständlich lassen sich damit nicht alle Einsatzfälle abdecken - dort, wo diese Lösungen funktionieren, ist die Nutzung der bestehenden Windows-Server-Plattformen in einem echten Final-Relase sinnvoller als der schnelle Schritt zum 64-Bit-Windows, das vor allem aus Marktgründen bereits herausgebracht wurde.

64-Bit-Windows: Mehr Speicher für das System

Es ist nicht unbedingt der maximal nutzbare physische Hauptspeicher, der die grösste Einschränkung bei 32-Bit-Windows-Systemen darstellt. Im System gibt es einige andere Speicherbeschränkungen, die viel früher zum Engpass werden können. So kann es beispielsweise, wie im Artikel Q247904 der Knowledge Base von Microsoft beschrieben, zu Problemen beim Kopieren sehr grosser Dateien kommen, weil der Auslagerungsbereich eines Systems nicht ausreicht. Dort wird 1 MB Platz pro GB zu kopierender Datei reserviert, wenn die Standard-Systemaufrufe von Windows NT und Windows 2000 verwendet werden. Erst ab dem Service Pack 2 von Windows 2000 wurden diese Aufrufe modifiziert, um die Einschränkung zu umgehen. Da der Auslagerungsbereich eine maximale Grösse von 470 MB hat und auch das System und andere Anwendungen darauf zugreifen, kann dieser Punkt vergleichsweise früh erreicht sein. Der Engpass kann dann beispielsweise beim Kopieren der Sicherungsdateien von sehr grossen Datenbanken auftreten.

Sowohl der Auslagerungsbereich als auch der Nichtauslagerungsbereich sind abhängig von der Grösse des physischen Hauptspeichers, können aber auch durch Registry-Parameter angepasst werden. Der Auslagerungsbereich ist ein Systemspeicherbereich, in den die Auslagerungsdatei verschoben werden kann. Diese Seiten werden von Anwendungen im Kernel-Modus reserviert. Systemanwendungen nutzen einen Bereich von 2 GB virtuellem Speicher. Ein wesentlicher Bereich davon ist eben der Auslagerungsbereich.

Ein zweiter wichtiger Bereich ist der Nichtauslagerungsbereich mit Seiten, die nicht ausgelagert werden dürfen. Daneben gibt es dann noch den Kernel-Stack, in dem Stacks für jeden Thread gehalten werden, der Systemaufrufe macht. Die Nutzung des Kernel-Stack wird in der System-PTE (Page Table Entry) verwaltet. Detaillierte Informationen dazu finden sich unter anderem in den Artikeln Q247904 und Q126402 der Microsoft Knowledge Base.

Generell gilt, dass alle Einschränkungen vom Auslagerungsbereich bis zum maximalen Cache, der vom Betriebssystem verwaltet werden kann, in einem Zusammenhang mit dem verfügbaren physischen Hauptspeicher stehen.

Bei den 64-Bit-Versionen von Windows gibt es diesen Zusammenhang in Teilen immer noch, weil beispielsweise bei 4 GB installiertem Hauptspeicher nicht einfach 2 oder 3 GB für den Auslagerungsbereich verwendet werden können, da Anwendungen und Cache ja ebenfalls Hauptspeicher belegen. Die Flexibilität in der Nutzung des Hauptspeichers wurde aber erhöht und die Grenzen deutlich nach oben verschoben.

Dies war ein "kleiner" Exkurs in Sachen Windows.Net Server,man darf gespannt sein !

Quelle: Infoweek

Cerberus :)