Frühjahrsputz
Trotz der üblichen Verspätung und mehrerer Namensänderungen sollte die Familie der Windows Server 2003 bei Erscheinen dieser Ausgabe in den Regalen der Händler stehen. iX hat auf Basis endgültiger Versionen eine erste Annäherung an das aktuelle Microsoft-Flaggschiff unternommen.
- Peter Nolte
- Dr. Holger Schwichtenberg
- Sebastian Weber
- Wolfgang Möhle
Vom Namen her hat der neue Server aus Redmond eine bewegte Geschichte. Entwickelt unter dem Codenamen „Whistler“ sollte er erst „Windows Server 2002“ heißen, doch das hauseigene .Net-Marketing machte ihn zum „Windows .Net Server“. Im September 2002 wurde die Jahreszahl 2003 ergänzt („Windows .Net Server 2003“) und schließlich verkündete Microsoft Anfang dieses Jahres, dass das Produkt nur noch „Windows Server 2003“ heißt, aber ein Logo „.Net Connected“ (siehe hierzu gleichnamigen Kasten) trägt. Damit hatte das neue Serverbetriebssystem sein „.Net“ im Namen verloren.
.Net Connected
.Net Connected ist ein Logo-Programm von Microsoft für .Net-Anwendungen. Gemäß eigener Definition kann eine Anwendung die Bezeichnung bekommen, wenn sie auf dem .Net Framework beruht und als eine primäre Funktion XML Web Services bereitstellt oder nutzt. Wendet man diese Voraussetzungen auf das neue Betriebssystem an, hätte der Windows Server 2003 das .Net Connected Logo nicht erhalten dürfen.
Basis für diesen Artikel sind die deutsch- beziehungsweise englischsprachigen Final-MSDN-Versionen des Advanced Server.
Bleibt die Frage, wie man sich der Analyse eines Betriebssystems nähert, dessen Dokumentation und Sekundärliteratur in den nächsten Monaten ganze Regale füllen wird? iX wird die Betrachtung auf die folgenden zentralen Bereiche konzentrieren:
- .Net Framework 1.1:
Was ist .Net am neuen Server? - Active Directory:
Änderungen und Erweiterungen zum Windows 2000 Server; - Storage Management:
Neuerungen im Bereich Datei- und Massenspeicher; - Security:
erweiterte Public-Key-Infrastruktur einschließlich Domain-weiter Zertifizierung; - IIS 6:
Der 2003er-Server enthält einen von Grund auf neu konzipierten Webserver; - Terminal Server:
Hier gibt es unter anderem ein aufgebohrtes RDP-Protokoll; - Lizenzen:
Leistungsgrenzen und neue Lizenzierungsformen.
Da aber auch diese Eingrenzungen bereits den Rahmen eines Artikels sprengt, müssen wir die Teile Security, IIS 6 und Terminal Server in der folgenden Ausgabe nachliefern.
Alles hat seine Geschichte
Die Entwicklungszyklen signifikant neuer Betriebssysteme werden (nicht nur) bei Microsoft immer kürzer (siehe Grafik „Microsofts Betriebssysteme“). Erkennbar ist aber eine mittelfristige Strategie: Die DOS-basierten Systeme (von DOS selbst bis hin zu Windows 98) sind ausgelaufen, zudem hat Microsoft den Gleichklang der 32-Bit-basierten Workstation- und Serverbetriebssysteme (von NT bis Windows 2000) über Bord geworfen.
Alle Clientsysteme bündeln sich in XP (wobei sich die Home-Edition bekanntlich nur um Nuancen von der Professional unterscheidet), und die Servervarianten gehen nun ihren eigenen Weg. Vielleicht hat Microsoft inzwischen eingesehen, dass der Spagat zwischen einem auf Grafik-Performance ausgelegten Einzelplatzsystem und einer für Rechenzentren gedachten 64-Bit-Enterprise-Version doch zu groß ist.
.Net Framework
An die Frage der .Net-Haftigkeit des neuen Servers könnte man über die Produktdokumentation herangehen, oder analytisch, indem man einfach die vom Windows-Setup installierten Dateien untersucht. Statt jede einzelne Datei mit dem Intermediate Language Disassembler (ildasm.exe - Teil des kostenlosen Framework SDK) - zu untersuchen, bot es sich an, ein kleines Werkzeug zu schreiben: Das Net-O-Meter (netometer.exe) liefert eine Liste aller .dll- und .exe-Dateien in einem bestimmten Dateisystempfad, die Managed Code für die Common Language Runtime (CLR) sind. Das Tool, das selbst in Managed Code geschrieben ist, gibts kostenlos unter [1].
Nach der Standardinstallation eines englischen Windows 2003 Advanced Server - ohne die Aktivierung irgendwelcher Serverrollen - liefert der Aufruf von netometer.exe c:\ ein auf den ersten Blick passables Ergebnis: Immerhin 136 der 4156 installierten .dll- und .exe-Dateien sind Managed Code (3,27 %). Schaut man sich die Liste der Dateien an, bemerkt man schnell, dass es sich nur um Dateien in den Verzeichnissen \windows\Microsoft. Net\Framework\v1.1.4322\, \windows\ assembly\GAC\ und \windows\system32\dllcache\ handelt. Nur das Framework selbst ist also in Teilen in Managed Code geschrieben - kein einziger Basis-Baustein des Betriebssystems basiert auf dem .Net Framework. Eine wirkliche .Net-Anwendung ist nur die Zusatzkomponente UDDI Service: Sie ist in Form einer ASP.Net-Webanwendung mit einigen in Managed Code verfassten .Net-Komponenten und Kommandozeilenwerkzeugen (Abb. 2) erstellt.
Marginales Framework-Face-Lifting
Erstmalig gehört bei einem Windows-Betriebssystem das .Net Framework zum Standardinstallationsumfang; es ist die Version 1.1.4322.573 und wird vom Windows-Setup in das oben genannte Verzeichnis gesteckt. Wie bei der Vorgängerversion 1.0 findet man in diesem Verzeichnis die .Net-Klassenbibliothek in Form von DLLs, XML-Konfigurationsdateien, die Kommandozeilencompiler für VB.Net, C# und JScript.Net, weitere Kommandozeilenwerkzeuge sowie eine MSC-Konsole. J# ist als Sprache verfügbar, jedoch weiterhin ein Add-on. An der Versionsnummer 1.1.4322.573 ist interessant, dass diese sich zwischen der Beta 1 und der Endfassung in den ersten drei Zahlenblöcken nicht geändert hat. Beim Framework 1.0 stieg die Revisionsnummer (3. Block) zwischen Beta 1 und der Endfassung immerhin von 2204 auf 3705.
Die MSC-Konsole mit dem Namen .Net Framework 1.1 Configuration (mscorcfg.msc) erleichtert die Erstellung von XML-Konfigurationsdateien für .Net-Anwendungen und das Framework selbst. Diese grafische Konsole kann aber dennoch nicht verhindern, dass mit dem Framework unerfahrene Serveradministratoren erheblichen Lernaufwand bezüglich der neuen administrativen Möglichkeiten und Einschränkungen haben. Zwar nicht neu in Vergleich zum Framework 1.0, aber dennoch bemerkenswert ist die Standardeinstellung der Code Access Security (CAS): Jeglicher Programmcode, der nicht auf der lokalen Festplatte des Servers liegt, läuft nur unter eingeschränkten Rechten. Dies gilt auch für Netzlaufwerke.
Die Veränderungen zwischen dem .Net Framework 1.0 und der Version 1.1 sind gering [2]. Microsoft hat einige frühere Add-ons nun ins Framework integriert. So gehören die ADO.Net Data Provider für ODBC-Treiber und Oracle-Datenbanken nun zum Kern des Framework, wobei sich allerdings der Namespace geändert hat: Von Microsoft.Data.Odbc zu System.Data.Odbc und Microsoft.Data.OracleClient zu System.Data.OracleClient. Die Änderungliste an bestehenden Namespaces der .Net-Klassenbibliothek [3] ist im Vergleich zu früheren Listen dieser Art überschaubar. Wirkliche konzeptionelle Neuerungen im Framework 1.1 sind nur die Code Access Security für ASP.Net und die Unterstützung für das Internet Protocol Version 6.0.
Das Framework 1.0 und 1.1 können auf einem System koexistieren, das heißt, der Windows Server 2003 verträgt die Nachinstallation des alten Framework. Sofern beide Versionen auf dem System vorhanden sind, bevorzugen .Net-Anwendungen jeweils die Version, für die sie entwickelt wurden. Anwendungen für Version 1.0 lassen sich beim Fehlen von Framework 1.0 auch mit 1.1 ein, andersherum verweigert eine 1.1-Anwendung die Arbeit, wenn es nur das Framework 1.0 gibt. Durch einen Eintrag in der globalen Konfigurationsdatei machine.config ist dieses Verhalten jedoch änderbar.
Die zentralen Features des neuen Active Directory und des Storage Management sowie die Hardwaregrenzen der einzelnen Versionen und das neue Lizenzmodell sind in der aktuellen Printausgabe beschrieben. (wm)
