Windows ohne Windows

Bei Windows-Betriebssystemen bestehen kaum überschaubare Abhängigkeiten zwischen den einzelnen Systemkomponenten, die es dem Admin erschweren, Unnötiges zu entfernen. Die nächste Server-Version, derzeit noch unter dem Namen „Longhorn“ im Betastadium, soll erste Schritte zu einem modularen Systemaufbau anbieten.

Kartellwächter, die die enge Verzahnung von Anwendungen und Betriebssystemfunktionen in verschiedenen Windows-Versionen kritisieren, bilden gewissermaßen nur die Spitze des Eisbergs. Problematischer als die Integration des Internet Explorer oder des Windows Media Player stellen sich für viele Administratoren und Entwickler die zahlreichen Querverbindungen und Voraussetzungen dar, die Windows unter seiner gefälligen Oberfläche oft schwer erziehbar machen.

Wer ein Serversystem mit einer eng umrissenen Aufgabe wirklich abspecken und härten will, findet nur wenige Möglichkeiten, Komponenten zu deinstallieren und Dienste abzuschalten. So bleibt in den meisten Fällen ein unnötig großer Satz an Funktionen und Schnittstellen übrig, die überwacht, gepatcht und mit Systemressourcen versorgt sein wollen.

Kernserver für Kernaufgaben

Der kommende Windows-Server, der auf derselben Code-Basis wie Windows Vista entwickelt wird und immer noch dessen ehemaligen Decknamen „Longhorn“ verwendet, bietet zumindest eine Option, mit der sich gezielt ein One-Task-Only-System aufbauen lässt. Microsoft bezeichnet dies als „Server Core“: Gemeint ist eine Installationsvariante des Betriebssystems, die nur einige wesentliche Grundfunktionen enthält. Ein solcher Core-Server lässt sich nur als Datei- und Infrastrukturserver aufsetzen - zum Datenbank- oder Applikationsserver taugt er nicht. Dafür bietet er deutlich weniger Angriffsfläche als vollwertige Windows-Server und soll damit leichter zu pflegen sein, denn die Patches, die sich auf nicht vorhandene Komponenten beziehen, sind unnötig.

Das Szenario, das die Redmonder im Auge haben, sind kleine Außenstellen, in denen die üblichen Windows-Serverfunktionen ohne großen Aufwand und großes Risiko bereitstehen sollen. Daneben kann Server Core als Abteilungsserver im normalen Maschinenpark dort interessant sein, wo nur die durch ihn abgedeckten Aufgaben zu erfüllen sind.

Im derzeitigen Evolutionsstand kann er folgende Dienste anbieten: Dateiserver, Domänen-Controller für Active Directory, DNS- sowie DHCP-Server und Medien-Streaming. Bis Redaktionsschluss war es noch nicht möglich, Druckdienste auf einem Core-Server einzurichten, weil hierzu die Abhängigkeiten vom (nicht vorhandenen) Grafiksystem aufgelöst werden müssen. Dem Vernehmen nach wird in Redmond daran gearbeitet. Ob es bis zur Release soweit ist, ist noch unklar.

Neben den Kerndiensten stehen einige weitere Funktionen zur Verfügung. Für den Einsatz in kleinen Niederlassungen ist die Festplattenverschlüsselung BitLocker interessant, die dem physischen Zugriff eines Angreifers seinen Schrecken nimmt. Zudem bietet der abgespeckte Server Unterstützung für das Failover-Clustering und für Network Load Balancing. Ersteres macht das System attraktiv, während die zweite Variante klassischerweise für Webserver oder Terminaldienste genutzt wird, diese Dienste stehen hier aber nicht zur Auswahl.

Dass das mit dem „richtigen“ Longhorn Server ausgelieferte Backup-Programm zur Core-Variante gehört, ist beruhigend, wenn auch das Programm selbst nur Grundbedürfnisse abdeckt (s. Kasten „Neuheiten im Longhorn Server“). Für Administratoren heterogener Umgebungen mag das installierbare Subsystem für Unix-Applikationen interessant sein, denn es ermöglicht die durchgängige Nutzung grundlegender Werkzeuge aus der Unix-Welt.

Zum Kern vordringen

Die Installation des Core-Servers verläuft zunächst scheinbar wie eine normale Einrichtung von Longhorn. In einem der wenigen Fenster des Setup-Assistenten wählt der Admin aus, ob es sich um einen Core-Server oder um eine vollwertige Installation handeln soll. Das war es auch schon fast, der Rest der Optionen ist praktisch identisch. Die Core-Installation spült gut ein Gigabyte Daten auf die Festplatte. Das ist zwar nur etwa ein Drittel einer typischen Vollinstallation, angesichts der drastischen funktionalen Beschränkung aber nicht eben umwerfend wenig.

Auch der Startvorgang des Kernsystems sieht nicht anders aus als beim großen Bruder, er ist allerdings erfreulich kurz. Der Kulturschock findet erst nach der Anmeldung statt: Auf beruhigend blauem Grund öffnet sich ein schwarzes Fenster mit Kommandoprompt. Das war es. Mehr Oberfläche bietet er seinen Administratoren nicht (s. Abbildung 1). Der in allen anderen Versionen für das GUI zuständige Explorer, der ja nicht nur das Dateisystem darstellt, sondern auch den Desktop oder das Startmenü, gehört nicht zum Installationsumfang, und er lässt sich konsequenterweise nicht nachrüsten. Wer eine solche Maschine zu verwalten hat, tut gut daran, seine Kenntnisse in der klassischen Windows-Shell (von vielen immer noch abschätzig als „DOS-Fenster“ bezeichnet) aufzufrischen und auszubauen.

Notabene: Gemeint ist tatsächlich die altehrwürdige Shell mit ihren Konsolenprogrammen und der simplen Batch-Sprache. Die von Microsoft kürzlich mit großem Aufwand in den Markt gebrachte PowerShell ist nicht enthalten. Und auch hier gilt: Nachrüsten ist nicht. Denn die PowerShell setzt das .Net Framework voraus, und das gibt es im Kernserver ebenfalls nicht. Der Umfang von .Net mit seinen Unmengen an Querverbindungen ins System hätte das Konzept zunichte gemacht. Auch auf die Segnungen des objektorientierten Scripting muss ein Core-Admin also verzichten.

Fernbeziehungen mit Appeal

Meist wird es aber nicht notwendig sein, einen Server auf der lokalen Konsole zu verwalten. Die gängigen Remote-Administrations-Tools lassen sich auch auf ein solches System ansetzen, wenn es einmal grundlegend eingerichtet ist. Im täglichen Betrieb wird die Netzwerkverwalterin also kaum einen Unterschied bemerken, denn von ihrem Admin-PC aus kann sie ihre MMC-Verwaltungskonsolen unterschiedslos mit einem ausgewachsenen Windows-Server und mit Core-Maschinen verbinden. Sogar ein Terminal-Zugriff per RDP ist zu administrativen Zwecken möglich - aber er gibt natürlich wiederum nur das Kommando-Fenster zurück, denn mehr grafische Darstellung beherrscht Server Core nun mal nicht.

Selbst die zentrale Verwaltung über das Netzwerk gelingt mit dem abgespeckten System. Der Client für die Verarbeitung von Gruppenrichtlinien, seit Windows Vista als eigener Dienst implementiert, ist vorhanden. So fügt sich ein Kernserver in das Konfigurations- und Sicherheitsgefüge des Unternehmens ein, zumal der „Windows Script Host“ (WSH) zur Verfügung steht, der die Automatisierung von Aufgaben mit „Visual Basic Script“ (VBS) ermöglicht. Eine wichtige Komponente lässt sich ausschließlich remote einrichten: die eingebaute Longhorn-Firewall. Sie kann man aus der Ferne per NetShell (netsh) oder mit der grafischen MMC-Konsole konfigurieren.

Alles auf mein Kommando

Viele Windows-Admins dürften mit der Ersteinrichtung des Core-Servers ihre liebe Not haben. Bewährt hat sich die Empfehlung, als Erstes mit

start cmd /separate 

ein zusätzliches Kommandofenster zu öffnen, denn wer das erste versehentlich schließt, sitzt vor einem leeren blauen Bildschirm. Zwar lässt sich über den Taskmanager ein neuer CMD-Prozess starten, und notfalls könnte man sich neu anmelden, doch mit doppeltem Boden arbeitet es sich entspannter. In früheren Betaversionen hat Server Core das zweite Fenster sogar gleich selbst geöffnet.

Grundlegenden Optionen müssen zunächst direkt auf dem System gesetzt werden, damit es überhaupt übers Netz ansprechbar ist. Neben einem sicheren Kennwort für das Adminkonto gehören dazu der Servername (den Setup temporär vorbelegt hat) und natürlich die IP-Adresse. Da der Longhorn Server wie Vista eine native IPv6-Implementierung mitbringt, muss bei allen Arbeiten an der Netzwerkkonfiguration das gewünschte Protokoll angegeben werden, heutzutage meist noch IPv4.

Eine Auflistung aller Netzwerkadapter gelingt also mit

netsh interface ipv4 show interface

Die LAN-Integration lässt sich durch

netsh interface ipv4
set address "Local Area Connection"
static 192.168.217.102  
   255.255.255.0
192.168.217.1

bewerkstelligen; den Namen in Anführungszeichen liest man im Ergebnis von show interface ab. Auf dieselbe Weise lassen sich DNS- und WINS-Server eintragen. Die Onlinehilfe von netsh gibt die nötigen Auskünfte.

Um den Server umzubenennen, wird dasselbe Werkzeug eingesetzt wie bei der Aufnahme in die Active-Directory-Domäne. Dabei handelt es sich um das ehemals separate netdom, das mit

netdom renamecomputer     
   ALTERNAME
/newname:NEUERNAME
/force
/reboot:30

auch gleich den nötigen Neustart durchführt.

Für einige Aktionen gibt es keine fertigen Kommandos. Hierfür liefert Microsoft einen Satz von VBS-Skripten mit. Dazu zählt SCregEdit.wsf, das über die Registrierungsdatenbank Funktionen wie den administrativen RDP-Zugriff oder Automatic Update freischaltet und die Konfiguration von DNS-Einträgen für Active Directory zulässt. Die Systemsteuerung beruht auf dem Explorer und ist daher nicht verfügbar. Ausnahmen hiervon: Die Zeitzone lässt sich über

control timedate.cpl 

anpassen, und die Regionaleinstellungen setzt der Administrator mit

control intl.cpl

Rollenspiel mit Ansage

Wer jetzt den Eindruck hat, dass die Core-Administration nicht unbedingt konsistent ist, sieht sich bei der Auswahl der möglichen Server-Rollen bestätigt. Direkt nach der Installation sind nur die grundlegenden Dateidienste vorhanden, damit die Remote-Administration überhaupt funktioniert. Alle weiteren Dienste und Funktionen muss der Verwalter erst einrichten. Dazu dient das Programm ocsetup.exe, dessen Optionen Windows-untypisch zwischen Groß- und Kleinbuchstaben unterscheiden. Die Nutzung ist recht einfach: Übergibt man dem Programm den Namen der gewünschten Rolle, so wird diese installiert. Hängt man /uninstall hinten an, entfernt das System sie wieder. Die vorhandenen Rollen gibt oclist.exe aus (s. Abb. 1).

Wenig überzeugend ist allerdings die Benennung der Rollen und Funktionen, denn das Namensschema ist uneinheitlich. Die DNS-Serverrolle hört auf DNS-Server-Core-Role, der DHCP-Dienst hingegen auf DHCPServerCore. Da die Dateidienste immer vorhanden sind, lassen sich dafür nur Erweiterungen nachinstallieren, deren Namen im einfachsten Fall SIS lauten (für Single Instance Store, ein Feature zur Reduktion des Speicherplatzbedarfs) und im umständlichsten DFSR-Infrastructure-ServerEdition (dahinter verbirgt sich die Dateireplikation DFS-R).

Fürs Active Directory wiederum setzt man nicht ocsetup.exe ein, sondern das bekannte Dienstprogramm dcpromo.exe. Es kann allerdings nicht wie gewohnt den grafischen Assistenten anzeigen, sondern verlangt nach einer Antwortdatei, die die nötigen Konfigurationsparameter angibt. Entgegen dem allgemeinen XML-Trend wird die Antwortdatei klassisch im Format Parameter=Wert aufgebaut (s. Listing). Als kleine Erleichterung kann der Administrator auf einem Longhorn Server den grafischen Assistenten ausführen und die dort gesetzten Einstellungen als Antwortdatei exportieren.

[DCINSTALL]
ParentDomainDNSName=ad.contoso.com
UserName=domadmin
Password=geheim
NewDomain=child
ChildName=longhorn.ad.contoso.com
NewDomainDNSName=longhorn.ad.contoso.com
DomainNetBiosName=longhorn
ReplicaOrNewDomain=domain
DomainLevel=3
DatabasePath="C:\Windows\NTDS"
LogPath="C:\Windows\NTDS"
SYSVOLPath="C:\Windows\NTDS\Sysvol"
AutoConfigDNS=yes
DNSDelegation=yes
DNSOnNetwork=yes
SafeModeAdminPassword=ganzgeheim
RebootOnCompletion=yes

Die Detailkonfiguration aller Dienste und Funktionen wird die Windows-Verwalterin in der Regel remote per MMC vornehmen. Alternativ lässt sich die Kommandozeile nutzen, dann aber wieder mit Standardprogrammen wie dnscmd.exe für DNS oder netsh für DHCP.

Fazit

Server Core ist ein interessanter Schritt in die richtige Richtung: Im Markt besteht großer Bedarf an Windows-Servern, die weniger überladen sind als die bisher bekannten Standardsysteme. Zwar zeugte schon der 2003-Server vom Umdenken in Redmond, seine Server künftig auf das Nötige zu beschränken und alle Spezialitäten nur auf Anforderung einzurichten. Auch setzt der Longhorn Server dieses Bemühen in seiner Grundinstallation fort. Aber die Möglichkeit, ein wirklich abgespecktes System ohne das vielfach verspottete „Klicki-Bunti“ aufzusetzen, fehlte bislang. Wenn Microsoft wirklich - wie gemunkelt - am völlig modularen Betriebssystem arbeitet, wäre das bahnbrechend.

Der tatsächliche Entwicklungsstand der Post-Beta-2-Installation enttäuscht in dieser Hinsicht allerdings. Die momentane Implementierung des Core-Servers umfasst allzu wenige Serverfunktionen, zumal die Nutzung als Druckserver momentan noch nicht vorhanden ist. Zudem ist die Admin-Schnittstelle per Kommandozeile alles andere als einladend: Ein liebloser Mischmasch aus verschiedenen Rudimenten ohne jede Konsistenz. Den typischen Windows-Administrator wird Microsoft so kaum zum Einsatz eines Kern-Servers bewegen. Für das angepeilte Szenario der kleinen Niederlassung kann Server Core trotzdem interessant sein: Die Funktion des Infrastruktur- und Dateiservers mit der zusätzlichen Absicherung über die Verschlüsselung BitLocker und den „Nur-Lese-Modus“ für Active Directory könnte durchaus den Bedarf decken. Fehlt eben nur noch der Druckserver - ob man dafür einen Pinguin nehmen muss?

Nils Kaczenski
ist Microsoft MVP für Windows Server Directory Services und arbeitet als Consultant in Hannover.